[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: real LSB compliance

On Sat, Jun 30, 2001 at 10:51:28PM -0700, Daniel Jacobowitz wrote:
> On Sun, Jul 01, 2001 at 03:28:31PM +1000, Christopher Yeoh wrote:
> > Daniel Jacobowitz writes:
> > > > [1] joey@silk:~/tmp>./usr/bin/lsblibchk 
> > > >    ./usr/bin/lsblibchk 1.0.0
> > > >    Unable to find library ld-lsb.so.1
> > > 
> > > Some LSB thing I assume :)  Everyone in the real world calls it either
> > > ld.so.1 or ld-linux.so.2 depending on their platform (roughly, maybe a
> > > few other names).
> > 
> > LSB compliant apps will need to link against /lib/ld-lsb.so.1. This
> > doesn't mean that Debian distributed packages have to do this but the
> > loader will have to be available.
> [trying not to start an argument, I'm sure this has been discussed at
> length, but...]
> What on earth is this supposed to accomplish?  As far as I know, every
> reasonably current Linux distribution for any particular architecture
> agrees on the name of the dynamic linker.

Not sure, but maybe they want to have a compatible linker for LSB
packages just like they want compatible shared libraries.

Example:  By tracking Debian testing, I somewhere lost the ability to
run my Maple binaries.

[andreas@merv andreas]$ xmaple
/usr/local/maple/bin.IBM_INTEL_LINUX_REDHAT/xmaple6: error while loading shared libraries: /usr/local/maple/bin.IBM_INTEL_LINUX_REDHAT/libc.so.6: symbol _dl_debug_impcalls, version GLIBC_2.0 not defined in file ld-linux.so.2 with link time reference

It comes with its own libc and ld-linux.so.  It does attempt to use its
own libc, however /lib/ld-linux.so is hardcoded and I haven't found a
way to make it use the version it comes with (short of setting up a

Andreas E. Bombe <andreas.bombe@munich.netsurf.de>    DSA key 0x04880A44

Reply to: