[maemo-developers] Scratchbox cs2007q3-glibc2.5-arm7 toolchain support?

[From: josh.soref at nokia.com]

Ben wrote:
> Trying to run this on an n810 gets
> foo at n810 hello-world $ ./hello 
> ./hello: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found
> (required by ./hello)

Welcome to the wonderful world of c++ and glib versioning.

> FWIW the normal C only hello-world compiled with the new 
> toolchain runs fine on the n810.

> It doesn't require any newer libraries it would seem.

> What is the recommended solution for folks wanting to use the more
> recent g++ and toolchain? The new linking method is supported 
> out of the box for the more recent ld in this toolchain ;)

I haven't tried it, but personally I'd try to downgrade the scratchbox
libstdc++.so so that it's the same one used by the older scratchbox.
That's ideal, since what you want is the new compiler and the new
linker, but the same libc as your target.

If you can't do that, you should be able to point the build system to
the old libc++ and say "don't link against the compiler's libc++".

> I could imagine doing similar things to the things that were mentioned
> on a recent thread about glib.

Pretty much. In the end I think it's probably best for the community to
maintain a /usr/maemo/lib which when created is added to /etc/ld.so.conf
and when files are added here ldconfig gets run.

> The quick and dirty version being having
> a personal lib directory and forcing its use with LD_LIBRARY_PATH in a
> little wrapper script for any tools I compile like:

Yep, this is the standard mozilla approach for libraries.

The theoretical downside for embedded devices is that you will run out
of space if everyone ships their own copy of each library c++ (it's 740k
today).

> $ gcc4-launch foo
> Or forcing the scratchbox to link to 
> libstdc++.so.6.0.9 instead of
> libstdc++.so.6
> and just shoving the libstdc++.so.6.0.9 into /usr/lib and being done
> with it.

This becomes problematic, if you're going to do it, please coordinate w/
the community to make sure that there's an actual package for it and
that you depend on it, otherwise when a second provider has it, they'll
conflict with you, which will suck.

> I thought I'd throw it out there in case someone is using this newer
> toolchain and has a solution.

Fwiw the mozilla mobile - fennec people intend to use the newer
toolchain for their release (if they ever make one?), so you could wait
and see what they do. Offhand I'd expect them to go the LD_LIBRARY_PATH
route since that is what gecko traditionally does.