Bug#225397: ldconfig installs link which gcc cannot use
Package: libc6
Version: 2.3.2.ds1-10
Severity: important
Tags: sid
The report that follows is copied from an email sent to Mathias Klose:
Camm Maguire writes:
> Hi Matthias! And thanks for your report!
>
> 1) There appears to be a functional change in ldconfig, presumably
> part of the libc6 package. On woody, we have the following:
>
> ls -l /usr/lib/liblapack*
> -rw-r--r-- 1 root root 5746432 Oct 29 2002 /usr/lib/liblapack.a
> lrwxrwxrwx 1 root root 14 Feb 4 2003 /usr/lib/liblapack.so -> liblapack.so.2
> lrwxrwxrwx 1 root root 16 Feb 4 2003 /usr/lib/liblapack.so.2 -> liblapack.so.2.0
> -rw-r--r-- 1 root root 4205508 Oct 29 2002 /usr/lib/liblapack.so.2.0
> lrwxrwxrwx 1 root root 31 Apr 22 2002 /usr/lib/liblapack2.so -> /etc/alternatives/liblapack2.so
> lrwxrwxrwx 1 root root 22 Apr 22 2002 /usr/lib/liblapack_atlas.so.2 -> liblapack_atlas.so.2.3
> -rw-r--r-- 1 root root 53492 Apr 13 2002 /usr/lib/liblapack_atlas.so.2.3
> -rw-r--r-- 1 root root 5899904 Oct 29 2002
> /usr/lib/liblapack_pic.a
>
> Note that ldconfig, run when the package is installed, has
> reestablished the link
>
> /usr/lib/liblapack.so -> liblapack.so.2
>
> which is in the lapack package itself.
>
> Note also that these packages provide, at user request, a virtual
> 'lapack2-dev' package via the alternatives system. -llapack2 will
> allow compiling against lapack with either lapack-dev or any of
> the atlas2-dev packages installed.
>
> Unfortunately, on sid we have the following:
>
> ls -l /usr/lib/liblapack*
> lrwxrwxrwx 1 root root 13 Dec 16 15:54 /usr/lib/liblapack.so.2 -> liblapack2.so
> -rw-r--r-- 1 root root 4438832 Jul 31 23:20 /usr/lib/liblapack.so.2.0
> lrwxrwxrwx 1 root root 31 Jun 6 2003 /usr/lib/liblapack2.so -> /etc/alternatives/liblapack2.so
> -rw-r--r-- 1 root root 142356 Jun 20 23:43 /usr/lib/liblapack_atlas.a
> lrwxrwxrwx 1 root root 20 Aug 30 00:20 /usr/lib/liblapack_atlas.so -> liblapack_atlas.so.2
> lrwxrwxrwx 1 root root 22 Aug 30 00:20 /usr/lib/liblapack_atlas.so.2 -> liblapack_atlas.so.2.3
> -rw-r--r-- 1 root root 53024 Jun 20 23:43 /usr/lib/liblapack_atlas.so.2.3
>
> Here ldconfig has made liblapack.so.2 point to liblapack2.so, the
> "lapack2-dev" virtual alternative link, which does not share the
> same base name, but does resolve to a library with the same
> soname, which is in turn processed before these libs due to the
> entries in /etc/ld.so.conf installed by the atlas packages
> (i.e. the resolution in this case is to
> /usr/lib/sse2/atlas/liblapack.so.2.3). This is rather odd, but
> should not be fatal, as one should equally be able to compile
> against any of these libraries and get the same result.
> Unfortunately, gcc does not appear to traverse such a link when
> called with -llapack, i.e. it will not follow the link to a
> library of a different name, liblapack2, (apparently). So this
> is a bug somewhere between gcc and the new libc6/ldconfig
> behavior. Would you mind filing it as such?
>
> 2) You can work around this for now by using -llapack2 -lblas2 on the
> command line. This restores your dynamic links in
> lapack_lite2.so.
>
> Take care,
>
> Matthias Klose <doko@cs.tu-berlin.de> writes:
>
> > Camm,
> >
> > please could you have a look at building the current python-numarray
> > package? The build module
> >
> > Packages/build/lib.linux-i686-2.3/numarray/linear_algebra/lapack_lite2.so
> >
> > doesn't reference the lapack and the blas libs... any hints?
> >
> > I know this worked before ...
> >
> > If you build the package, please add a line at the begnning of the
> > rules file:
> >
> > DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
> >
> >
> > Matthias
> >
> >
> >
>
> --
> Camm Maguire camm@enhanced.com
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux intech66 2.4.20 #1 SMP Fri Jan 17 14:08:45 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7 The Berkeley database routines [gl
-- no debconf information
Reply to: