gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] cross-compiling for ARM / Angstrom: bugs and problems


From: Rob Savoye
Subject: Re: [Gnash-dev] cross-compiling for ARM / Angstrom: bugs and problems
Date: Sat, 11 Apr 2009 09:55:56 -0600
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Udo Giacomozzi wrote:

> Anyway.. I'm trying to cross-compile Gnash form a ARM-based PDA ("TDS
> Nomad", www.sdgsystems.com/Nomad/) and I ran into a few problems, one
> of which I cannot resolve.. 

  Interesting. I have an older SDG Systems "StudentMate", I had once
ported Gnash too. (it's only 200Mhz)

> 1) The "configure" script claimed that the QT development files are
> not installed. I think the problem is caused by this test:
> 
>   if test x"${build_qt4}" = xyes -a x"${ac_cv_path_qt4_incl}" = x; then
> 
> I think this should be
> 
>   if test x"${build_qt4}" = xyes -a ! x"${ac_cv_path_qt4_incl}" = x; then
> 
> Changing this line makes "configure" complete successfully.

  That change makes configure ignore the paths you specify for
--with-qt4-incl=. I'll see about tracking this bug down, as it looks
like something isn't getting set right when you use --with-qt4-incl=,
but the regular qt4 tests found the right parts anyway.

> 2) This is very odd. The Makefile for libcore seems to miss the Boost
> include path: 
> 
> ../libcore/StringPredicates.h:24:46: error: 
> boost/algorithm/string/compare.hpp: No such file or directory
> ../libcore/StringPredicates.h:25:48: error: 
> boost/algorithm/string/predicate.hpp: No such file or directory
> 
> I solved this by creating a symlink "libcore/boost"

  Boost and all the other libs should be found using --with-top-level (I
may change this to --sysroot soon), without any of the paths specified.
That's how I cross configure Gnash.

> 3) Now I can build a portion of Gnash but I get lots of warnings and
> finally it fails because of some overloaded operator:

  Patch in trunk now.

> I tried with Boost 1.35 and Boost 1.38 (same result) and with Gnash
> 1.3.5 (building fails on some Boost stuff in libbase) and a fresh Bzr
> Trunk checkout (result as described above). 

  I stick to boost 1.33 and 1.34 for all my cross-builds, due to issues
with Boost and non Intel processors.

> My "configure" options:
> 
> PATH=/opt/sdg/angstrom2007.12/sdk/bin:$PATH \
> CC=arm-angstrom-linux-gnueabi-gcc \
> GCC=arm-angstrom-linux-gnueabi-gcc \
> CXX=arm-angstrom-linux-gnueabi-gcc \
> STRIP=arm-angstrom-linux-gnueabi-strip \
> LD=arm-angstrom-linux-gnueabi-ld \
> ./configure \
>   --host=arm-linux \
>   --enable-fps-debug \
>   --enable-gui=qt4 \
>   --with-top-level=/opt/sdg/angstrom2007.12/sdk/arm-angstrom-linux-gnueabi \
>   
> --with-qt4-incl=/opt/sdg/angstrom2007.12/sdk/arm-angstrom-linux-gnueabi/include/qt4
>  \
>   --with-qt4-lib=/opt/sdg/angstrom2007.12/sdk/arm-angstrom-linux-gnueabi/lib \
>   --enable-mit-shm \
>   --with-boost-incl=../boost_1_38_0/boost \
>   --with-boost-lib=../boost_1_38_0/stage/lib \
>   --with-gif-incl=../giflib-4.1.6/lib \
>   --with-gif-lib=../giflib-4.1.6/lib/.libs \
>   --with-agg-incl=../agg-2.5/include \
>   --with-agg-lib=../agg-2.5/src \
>   --with-sdl-incl=../SDL-1.2.8/include \
>   --with-sdl-lib=../SDL-1.2.8/src/.libs 

  You shouldn't need to specify the tool chain executables.
--host=arm-angstrom-linux-gnueabi should do the trick. Gnash doesn't
care what the host is, the config triplet is used to find the tool
names. It's ok to specify them yourself, but should be unnecessary.

  I've primarily only tested the KDE4 support, QT4 (Qtopia 4) might have
some unique problems I haven't seen.

> And the "make" call:
> 
> PATH=/opt/sdg/angstrom2007.12/sdk/bin:$PATH \
> CC=arm-angstrom-linux-gnueabi-gcc \
> GCC=arm-angstrom-linux-gnueabi-gcc \
> CXX=arm-angstrom-linux-gnueabi-gcc \
> STRIP=arm-angstrom-linux-gnueabi-strip \
> LD=arm-angstrom-linux-gnueabi-ld \
>   make

  You shouldn't have to specify any flags at make time, even when cross
compiling. If you specify CC, etc... when configuring, these values get
inserted into the Makefile.

  The best way to track down configure issues is to set CONFIG_SHELL="sh
-x", and then run $CONFIG_SHELL ./configure [.....]" to get voluminous
debugging output that makes it pretty easy to see what is going on.

        - rob -




reply via email to

[Prev in Thread] Current Thread [Next in Thread]