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

Bug#225397: marked as done (ldconfig installs link which gcc cannot use)



Your message dated Sat, 17 Apr 2010 22:02:51 +0200
with message-id <20100417200251.GA1128@atlan>
and subject line Old bug, long fixed
has caused the Debian Bug report #224855,
regarding ldconfig installs link which gcc cannot use
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
224855: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224855
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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



--- End Message ---
--- Begin Message ---
Hi, 

I'm closing this bug report. Atlas 2 is long out of Debian and the usage
of Atlas 3 has changed significantly.

	Thomas


--- End Message ---

Reply to: