Re: Some questions on the LSB build environment

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

Well it depends on what timescale you mean, but at some point I'll see if I
can write a patch if none has been written by then.

> Encouraging library developers to use symbol versioning like libc is
> also a longer term way to avoid this problem.

I'm not convinced it is. Being able to break ABI compatability by bumping the
soname is useful, it means that as programs that use the old library are
phased out eventually the mistakes of the past can be sheared off. If all
libraries used symbol versioning, they would simply get larger and larger over
time. For glibc which simply cannot be upgraded or renamed, it's a good
solution. One idea I've seen proposed is for libraries to simply use blanket
symbol versioning and only provide 1 version for every symbol, which is simply
a way to work around this problem with ELF imho, as you don't actually gain
anything other than "unbreaking" ld.so and as such is an abuse of symbol
versioning itself.

I think it might be worth considering placing a caveat notice in the part of
the LSB dealing with this. At the moment it simply says, please refer to the
ELF specs. If the symbol search order were altered slightly so that the
DT_NEEDED entries of the binary being linked were searched first, you would be
able to have two major versions of the same library in the same address space
at once, and it'd suddenly become a lot easier to make portable binaries. As
the LSB already has its own linker, ld-lsb.so could be patched to alter this
search order, and it'd only affect LSB binaries. Having said that, nothing
should be affected by this change anyway, because you can't build a binary
unless all the symbols are resolved by the DT_NEEDED entries (as far as i'm
aware), so in theory it won't break anything. Investigation shows the patch
needed to ld.so would be small, as internally it already keeps track of
everything needed.
  
> 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.

Yes, I suppose we could do that (extend the stub), but I don't understand why
we'd have to. Surely the shipping 3rd party binaries could use the libc stub,
and libs pulled in from the distro installation, or from apt, could use the
standard system glibc with the latest versions of all the symbols. I don't
understand why the libc stub would have to be extended?
 
thanks -mike