[lsb-discuss] Some questions on the LSB build environment

Christopher Yeoh cyeoh at samba.org
Mon Feb 3 21:43:08 PST 2003


At 2003/2/3 12:04-0000  Mike Hearn writes:
> 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.

I'm not familiar enough with glibc and the linker to comment on
this. Have you suggested this on the glibc mailing list?

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

I think you will run into problems when attempting to link the binary
in the first place. Eg. say your binary links against libfoo which
uses the strfry glibc function which is not in the LSB. At compile
time when you attempt to link your binary using libc stub library it
will fail to find the strfry function and so fail to link.

Regards,

Chris
-- 
cyeoh at au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia




More information about the lsb-discuss mailing list