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 _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
