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
chroot).
--
Andreas E. Bombe <andreas.bombe@munich.netsurf.de> DSA key 0x04880A44
Reply to: