Re: Some questions on the LSB build environment

At 2003/2/3 10:17-0000  Mike Hearn writes:
> > In order to dynamically link against non lsb libraries I think you
> > will have to make some modifications to lsbcc or use lsbdev which will
> > allow you to more precisely control which libraries are statically or
> > dynamically linked. However if your non lsb shared library uses libc
> > interfaces not in the LSB then you won't be able to link.
>
> Is that because ld-lsb.so enforces the link rules of the LSB? If so, is there
> any way to disable that for a particular binary?
 
Its not ld-lsb.so which enforces this, but lsbcc (and lsbdev-chroot in
its default configuration where the only shared libraries in the
chroot are the ones required by the LSB). It would infact be useful to
be able to direct lsbcc (maybe through a config file?) to link some
non LSB libraries dynamically as this would also be needed by people
shipping non LSB shared libraries in their package. Its probably
something we'll end up doing ourselves, but feel free to send a patch :-)
 
> * Symbol namespace pollution: this means that I can't link in two libraries
> that offer the same symbol to the same address space, ie:
>
> frozen-bubble game compiled on newest mandrake:
> \-> libpng.so.3 (mandrake uses libpng.so.3)
> \-> libSDL (distro compiled libSDL against libpng.so.2)
>       \-> libpng.so.2
>
> Even though libpng appears in two separate places in the link tree, and so
> shouldn't interfere, the breadth-first search algorithm specified by ELF means
> they do in fact interfere, causing at best an instant segfault. The only
> solution currently is (of course) to recompile on the distro so now it links
> against libpng.so.2 like all the other libraries.
 
Encouraging library developers to use symbol versioning like libc is
also a longer term way to avoid this problem.
 
> binaries don't use symvers I can't guarantee are on the system, but I also
> need to be able to link against system libraries that were compiled with non
> LSB interfaces, even perhaps use optimized glibcs etc, because as they are
> already put on the system by the distro they don't really need to be LSB
> compliant: they are matched with the glibc.
>
> I think that's a long winded way of putting forward a fairly obvious
> problem.... but I'm wondering if the LSB can help me. I can't use it if it's
> an all or nothing issue, LSB and non-LSB libs have to be able to co-exist
> peacefully in the same process.
 
To do what you want in addition to making some changes to lsbcc (or
using lsbdev-chroot configured correctly) you'll need to generate a
new libc stub library that in addition to the LSB interfaces also
contains the other required glibc interfaces. I don't think it would
be too difficult to do this - I can probably help out a bit if you're
still interested.
 
Regards,
 
Chris
--
[email protected]
IBM OzLabs Linux Development Group
Canberra, Australia