[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
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
Re: [Gnash-dev] cross-compiling for ARM / Angstrom: bugs and problems, Rob Savoye, 2009/04/11
- Re[2]: [Gnash-dev] cross-compiling for ARM / Angstrom: bugs and problems,
Udo Giacomozzi <=