gnash-dev
[Top][All Lists]
Advanced

[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
location.

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
Qt/Embedded.

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.

Udo







reply via email to

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