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: Mon, 13 Apr 2009 09:21:16 -0600
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Udo Giacomozzi wrote:

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

  Ah, then that's what the --with-* options are for. I usually build my
own toolchains, and put everything together. I guess that's cheating...

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

  Basically it does two things. One is it changes behaviors in
configure, as you know it's a cross compiling environment. Then it
basically becomes a top level directory used when searching directories
include, lib, lib32, and lib64. as GCC uses --sysroot, I might rename
this as the way it works is the same.

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

 I'm at 10783.

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

  Both the SH4 and Loongson (MIPS) have obscure code generation bugs
with boost 1.34 or newer, so I use the older version as I don't have
time to fix the bugs.

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

  Since I had done this quite a while ago, it was to Qtopia2, and
involved a lot of autotools hacking. When I added KDE4 configure
support, I tried not to break the embedded QT/Qtopia support. AS I have
no Qtopia4 development environment, I didn't test it though, so the
config support for it is probably broken. Once the config is fixed, it'd
probably work with a little hacking.

> 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 ;)

  Gnash has become slower unfortunately, but I only notice on netbook
class hardware. :-( I was planning on doing some major performance
hacking, but want to finish RTMP hacking first.

        - rob -




reply via email to

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