[Top][All Lists]

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

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

From: Udo Giacomozzi
Subject: Re[2]: [Gnash-dev] cross-compiling for ARM / Angstrom: bugs and problems
Date: Mon, 13 Apr 2009 14:24:33 +0200

Hello Rob,

Saturday, April 11, 2009, 5:55:56 PM, you wrote:
RS>   Interesting. I have an older SDG Systems "StudentMate", I had once
RS> ported Gnash too. (it's only 200Mhz)

We had an older "Recon" model (also 200 MHz) but enver tried to port
Gnash to it (and the wlan implementation sucked, unfortunately).

>> I solved this by creating a symlink "libcore/boost"

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

I use --with-top-level to specify the location of the Nomad SDK
containing compiler and standard libs.

Boost and other libs are not included in that SDK so I had to download
and build them separately and thus they are found in a different

How does --with-top-level work exactly? Will it find all Boost files
if they are in a "boost_1_38_0" subdirectory below the top level? Note
I placed all extra libs (like Boost) in the same directory as the
Gnash executable, not in /lib or similar, since I want to avoid
messing too much with this evaluation device.

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

RS>   Patch in trunk now.

Hmm, when I try to update, it says:

  $ bzr update
  Tree is up to date at revision 10779.

But I received Gnash-commit mails with revision 10784. I'm new to
Bazaar, so no clue what's wrong here..

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

Don't know anything about these issues, but Gnash runs just fine.

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

I think Gnash currently requires X11 and so won't compile for
QT/Embedded. In a IRC discussion the QT4 GUI author mentioned some
relevant changes that should it make easier to support plain

Either way it whouldn't be too hard to do.
I'm completely new to Qt, though.

For the moment I disabled Qt on the device and run Gnash in
framebuffer mode, which works fine. It's a bit slow for a 800 MHz
processor (a 500 MHz Geode runs niticeably faster even in a higher
resolution - with a much older Gnash version, though). I hope it's
typical for an ARM processor and that Gnash did not become slower in
the past months ;)

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

Good to know. Will try next time.


reply via email to

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