Re: Maemo port - status update - CALL FOR ALPHA TESTERS!

From: Ryan Pavlik <abiryan_at_ryand.net>
Date: Sun Jan 27 2008 - 13:59:24 CET

Well, I have built a binary for Chinook (ITOS2008) devices, as well as
all the dependencies. I'd like someone with an actual device to test
it, because it acts a little odd (crashed on save, doesn't start from
the menu) on the Scratchbox, but that could be the fault of the ARM
emulator. I would release the address publicly here, but I do not want
such a poorly-tested and unpolished version widely distributed, and I'm
sure it would be if I told everyone about it.

Thus, if you are willing to test the package confidentially, please
email me OFF-LIST (that is, reply, not reply all) and I will let you
know the address and the order of the packages, since it's not in a
repository. The true AbiWord developer regular will already know where
I put it - if you figure it out, please keep it to yourself.

Thanks for your help!

Ryan

Ryan Pavlik wrote:
>
> That looks like it cleans up some problems introduced by the new build
> system in Trunk- I imagine Rob did the porting of the Maemo stuff
> before the 4.0 patch, but applied the build system update after the
> 4.0 patch (since I recognize some of that as being Maemo 3.2 stuff).
> I'd appreciate it if as you work on this patch, you keep in mind some
> way to build both for 4.0 and for earlier versions.
>
> I'm currently working on 2.6 (for a release), so this doesn't
> immediately help me, but it will be useful, and it may be that parts
> of the patch are useful in 2.6 as well.
>
> Thanks!
>
> Ryan
>
> Renato Araujo wrote:
>> Hy Rayn,
>>
>> I tried compile abiword to maemo last week and got some problems with
>> atotools scripts. I start some work to fix this, but I did not have
>> time to finish this yet, this is my initial patch maybe this can help
>> you.
>>
>>
>>
>>
>>
>>
>> On Jan 25, 2008 2:29 PM, Ryan Pavlik <abiryan@ryand.net> wrote:
>>
>>> Hey all! We've got the packaging moved over, which is great, and I've
>>> gotten all the dependcies to build and will be uploading those to the
>>> Maemo Garage soon. Now, I just have some trouble with the actual
>>> compiling aspect.
>>>
>>> I'm starting on Bora (Maemo 3.2 - ITOS 2007) because that's what I have
>>> hardware to test on: haven't upgraded my N800 yet and N810 didn't come
>>> before I left the country. According to this bug,
>>> http://bugzilla.abisource.com/show_bug.cgi?id=11242 - I can re-enable
>>> the tests for the older (pre-4.0) versions of Maemo - see comment
>>> #5. I
>>> am not very experienced with auto* and m4, but I did nest the old
>>> fallback test inside the fail part of the new one, and that allowed it
>>> to configure successfully.
>>>
>>> However, when building, it gets to some hildony stuff and stops. My
>>> commentary continues after the log:
>>>
>>> make[5]: Entering directory
>>> `/home/maemo/src/abi26/abiword/src/af/ev/unix'
>>> if g++ -DPACKAGE_NAME=\"abiword\" -DPACKAGE_TARNAME=\"abiword\"
>>> -DPACKAGE_VERSION=\"2.6.0\" -DPACKAGE_STRING=\"abiword\ 2.6.0\"
>>> -DPACKAGE_BUGREPORT=\"http://www.abisource.com/\" -DPACKAGE=\"abiword\"
>>> -DVERSION=\"2.6.0\" -DABIWORD_SERIES=\"2.6\" -DSTDC_HEADERS=1
>>> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
>>> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
>>> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
>>> -DSIZEOF_LONG_INT=4 -DEMBEDDED_TARGET_GENERIC=1
>>> -DEMBEDDED_TARGET_HILDON=2 -DEMBEDDED_TARGET_POKY=3
>>> -DEMBEDDED_TARGET=EMBEDDED_TARGET_HILDON -DENABLE_MENUBUTTON=1
>>> -DHAVE_PANGOFT2=1 -DWITH_ENCHANT=1 -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1
>>> -DHAVE_STRINGS_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1
>>> -DHAVE_MALLOC_H=1 -DCHECKED_ENDIANNESS=1 -DHAVE_LIBXML2=1 -DHAVE_WV=1
>>> -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DRETSIGTYPE=void
>>> -DABI_SCANDIR_SELECT_QUALIFIER=const -I. -I. -I/usr/include/gtk-2.0
>>> -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
>>> -I/usr/include/pango-1.0 -I/usr/include/freetype2
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>>> -I/usr/include/libglade-2.0 -I/usr/include/libxml2
>>> -I/usr/include/pango-1.0 -I/usr/include/freetype2
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>>> -I'../../../../src/af/util/xp' -I'../../../../src/af/tf/xp'
>>> -I'../../../../src/af/ev/xp' -I'../../../../src/af/ev/xp'
>>> -I'../../../../src/af/gr/xp' -I'../../../../src/af/xap/xp'
>>> -I'../../../../src/af/util/unix' -I'../../../../src/af/ev/unix'
>>> -I'../../../../src/af/gr/unix' -I'../../../../src/af/xap/unix'
>>> -I'../../../../src/af/xap/unix/hildon'
>>> -I'../../../../src/wp/ap/unix/hildon' -I'../../../../src/wp/ap/xp'
>>> -I'../../../../src/wp/impexp/xp' -I'../../../../src/wp/ap/unix'
>>> -I'../../../../src/wp/ap/xp/ToolbarIcons'
>>> -I'../../../../src/text/ptbl/xp' -I'../../../../src/text/fmt/xp'
>>> -I'../../../../src/text/fmt/unix' -Wall -pedantic -D_POSIX_SOURCE
>>> -D_BSD_SOURCE -pipe -DNDEBUG
>>> -I/scratchbox/devkits/doctools/include/libxml2 -I/usr/include/fribidi
>>> -I/usr/include/wv -I/usr/include/libgsf-1 -I/usr/include/glib-2.0
>>> -I/usr/lib/glib-2.0/include -I/usr/include/libxml2
>>> -I/usr/include/freetype2 -I/usr/include/freetype2
>>> -I/usr/include/libpng12 -DHAVE_THREADS=1 -pthread
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>>> -DABISIZEOF_LONG_INT=4 -I/usr/include/libgsf-1 -I/usr/include/glib-2.0
>>> -I/usr/lib/glib-2.0/include -I/usr/include/libxml2
>>> -I../../../../goffice-bits -I/usr/include/enchant
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DENABLE_SPELL
>>> -DPACKAGE_NAME=\"abiword\" -DPACKAGE_TARNAME=\"abiword\"
>>> -DPACKAGE_VERSION=\"2.6.0\" -DPACKAGE_STRING=\"abiword\ 2.6.0\"
>>> -DPACKAGE_BUGREPORT=\"http://www.abisource.com/\" -DPACKAGE=\"abiword\"
>>> -DVERSION=\"2.6.0\" -DABIWORD_SERIES=\"2.6\" -DSTDC_HEADERS=1
>>> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
>>> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
>>> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
>>> -DSIZEOF_LONG_INT=4 -DEMBEDDED_TARGET_GENERIC=1
>>> -DEMBEDDED_TARGET_HILDON=2 -DEMBEDDED_TARGET_POKY=3
>>> -DEMBEDDED_TARGET=EMBEDDED_TARGET_HILDON -DENABLE_MENUBUTTON=1
>>> -DHAVE_PANGOFT2=1 -DWITH_ENCHANT=1 -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1
>>> -DHAVE_STRINGS_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1
>>> -DHAVE_MALLOC_H=1 -DCHECKED_ENDIANNESS=1 -DHAVE_LIBXML2=1 -DHAVE_WV=1
>>> -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DRETSIGTYPE=void
>>> -DABI_SCANDIR_SELECT_QUALIFIER=const -I/usr/include/gtk-2.0
>>> -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
>>> -I/usr/include/pango-1.0 -I/usr/include/freetype2
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>>> -I/usr/include/libglade-2.0 -I/usr/include/libxml2
>>> -I/usr/include/pango-1.0 -I/usr/include/freetype2
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>>> -I/usr/include/freetype2 -I../../../../goffice-bits
>>> -DSUPPORTS_UT_IDLE=1 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
>>> -I/usr/include/atk-1.0 -I/usr/include/pango-1.0
>>> -I/usr/include/freetype2
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>>> -I/usr/include/hildon-fm -I/usr/include/dbus-1.0
>>> -I/usr/lib/dbus-1.0/include -I/usr/include/libosso-gsf-1
>>> -DABI_BUILD_VERSION=\"2.6.0\" -MT ev_UnixMenu.o -MD -MP -MF
>>> ".deps/ev_UnixMenu.Tpo" -c -o ev_UnixMenu.o ev_UnixMenu.cpp; \
>>> then mv -f ".deps/ev_UnixMenu.Tpo" ".deps/ev_UnixMenu.Po"; else rm -f
>>> ".deps/ev_UnixMenu.Tpo"; exit 1; fi
>>> ev_UnixMenu.cpp:61:34: hildon/hildon-window.h: No such file or
>>> directory
>>> ev_UnixMenu.cpp: In member function `virtual bool
>>> EV_UnixMenuBar::synthesizeMenuBar()':
>>> ev_UnixMenu.cpp:959: error: `HILDON_WINDOW' undeclared (first use this
>>> function)
>>> ev_UnixMenu.cpp:959: error: (Each undeclared identifier is reported
>>> only
>>> once for each function it appears in.)
>>> ev_UnixMenu.cpp:959: error: `hildon_window_set_menu' undeclared (first
>>> use this function)
>>> ev_UnixMenu.cpp: At global scope:
>>> ev_UnixMenu.cpp:339: warning: 'guint _ev_get_underlined_char(const
>>> char*)' defined but not used
>>> make[5]: *** [ev_UnixMenu.o] Error 1
>>> make[5]: Leaving directory
>>> `/home/maemo/src/abi26/abiword/src/af/ev/unix'
>>> make[4]: *** [all-recursive] Error 1
>>> make[4]: Leaving directory
>>> `/home/maemo/src/abi26/abiword/src/af/ev/unix'
>>> make[3]: *** [all-recursive] Error 1
>>> make[3]: Leaving directory `/home/maemo/src/abi26/abiword/src/af/ev'
>>> make[2]: *** [all-recursive] Error 1
>>> make[2]: Leaving directory `/home/maemo/src/abi26/abiword/src/af'
>>> make[1]: *** [all-recursive] Error 1
>>> make[1]: Leaving directory `/home/maemo/src/abi26/abiword/src'
>>> make: *** [all-recursive] Error 1
>>> [sbox-BORA_X86: ~/src/abi26/abiword] >
>>>
>>> I can see that it really starts failing on the missing include, which
>>> makes sense. That include was changed in the Maemo 4.0 patch:
>>>
>>> -#include <hildon-widgets/hildon-appview.h>
>>> +#include <hildon/hildon-window.h>
>>>
>>>
>>> I understand the removal of the old line, since that was deprecated.
>>> However, when looking in the Maemo 4.0 dev environment, I see no such
>>> <hildon/hildon-window.h> file! In maemo 3.2, there's a
>>> /usr/include/hildon-window.h file, which I think is probably
>>> what we need. In 4.0, the corresponding filename is in
>>> /usr/include/hildon-1/hildon/hildon-window.h leading me to believe that
>>> somewhere, includepath/hildon-1/ is being added to the includes.
>>>
>>> Thus to my possible solution. Where we are (presumably) including
>>> /usr/include/hildon-1 on Maemo 4.0, we include
>>> /usr/include/hildon-1/hildon/ instead, and remove the hildon/ from the
>>> #include lines in the source. Then, I presume that means that we can
>>> find /usr/include/hildon-window.h just as easily (and without adding to
>>> the include paths) as /usr/include/hildon-1/hildon/, and we return the
>>> already-extant OS 2006/2007 support to the code. This is just my
>>> hunch,
>>> however, I have not tried this particular solution yet, since I feel a
>>> bit over my head.
>>>
>>> I'm guessing that <hildon/hildon-window.h> might be an idiom, which
>>> would make this solution less desireable, but I don't see another way
>>> short of a bunch of ugly ifdefs.
>>>
>>> If someone with more experience could comment on this solution, point
>>> out my misdiagnosis of the problem, etc, that would be greatly
>>> appreciated. I'd really like to get this build off the ground!
>>>
>>> Ryan
>>>
>>> PS. In case you didn't notice, this is the 2.6 branch. Haven't tried
>>> tackling the new build system yet beyond some preliminary windows build
>>> tests.
>>>
>>>
>>
>>
>>
>>
>
>
Received on Sun Jan 27 14:01:51 2008

This archive was generated by hypermail 2.1.8 : Sun Jan 27 2008 - 14:01:52 CET