Re: Some questions on the LSB build environment

> Unfortunately, if you ship an app that dynamically links to
> a system library like qt or some gnome library, and that
> library links to some *other* libc than the one your app
> links to, you might run into serious trouble.  And glibc
> is going through some big changes now with respect to
> threading, so trouble is more likely than you might imagine.

I assume you're referring to the symbol fixup order problem that was
covered in the "Symbol fixup hell" thread on lsb-futures? I keep running
my head into this piece of wierdness. I can't see any good reason why
you shouldn't be able to have multiple versions of the same lib in a
single address space, ld.so internally could support this with only a
minor patch and it'd solve all kinds of portability problems. It's the
kind of thing that if anybody should sort out, it should be the LSB imo.

When you link against the LSB stub glibc/libX etc do you actually have
to have those stub libs present on the system, or are they simply used
at build time to force the linker to use the LSB versions of the libc
symbols?