Bug#224855: Processed: Re: Bug#227308: lapack: too many levels of symbolic links on so
Greetings, and thanks for your reply!
This bug affects several packages, so lets take lapack-dev as an
example. In the package itself, the link reads
liblapack.so -> liblapack.so.2
where the latter, provided in the lapack package, reads
liblapack.so.2 -> liblapack.so.2.0 (a file)
This is the normal setup. In addition, lapack-dev provides an
*alternative* link
liblapack2.so -> /etc/alternatives/liblapack2.so
which is set via the alternative mechanism to one of several choices,
e.g.
/etc/alternatives/liblapack2.so -> /usr/lib/liblapack.so
The problem is now that ldconfig will be run, and will change these
links. In woody, these links are rewritten to their original values,
and everything works. In sid, ldconfig rewrites the first link as
follows:
liblapack.so -> liblapack2.so
creating a link circle.
There is code in ldconfig which, it would appear, is intended to avoid
setting links to other links:
for (dlib_ptr = dlibs; dlib_ptr != NULL; dlib_ptr = dlib_ptr->next)
{
/* Don't create links to links. */
if (dlib_ptr->is_link == 0)
create_links (dir_name, entry->path, dlib_ptr->name,
dlib_ptr->soname);
if (opt_build_cache)
add_to_cache (entry->path, dlib_ptr->soname, dlib_ptr->flag,
dlib_ptr->osversion, hwcap);
}
I haven't debugged this extensively, so this code may be doing
something else, but in any case if this snippet was intended to avoid
this type of behavior, it is not working, unlike the case in woody.
I've also verified that a workaround is to set the *alternative* link
to something alphabetically less than the shared library link, e.g.
liblapack-2.so -> /etc/alternatives/liblapack-2.so
Apparently what is happening is that ldconfig traverses /usr/lib in
alphabetical order, finds liblapack.so.2 and links liblapack.so to it,
then finds liblapack2.so and relinks liblapack.so to it.
I've released reblas3, lapack3, and atlas3 packages (not yet
installed) with this workaround, i.e. the alternative allows a package
to link against a "virtual" lapack package (provided by either lapack
or atlas or both) as -llapack-3, not -llapack3. I have not changed
the soname=2 versions (blas, lapack, and atlas2) to do this, as there
are already packages which build against blas and lapack via -lblas2
and -llapack2. Changing the alternative name will break these builds,
not that it wouldn't be easy to fix if necessary, i.e. ldconfig could
not be fixed.
I'm a bit short on time right now, but if *really* necessary, I might
be able to run woody's and sid's ldconfig under gdb to spot the
difference.
Take care,
GOTO Masanori <gotom@debian.or.jp> writes:
> At Tue, 13 Jan 2004 19:34:24 -0600,
> Debian Bug Tracking System wrote:
> > > merge 227308 225397
> > Bug#225397: ldconfig installs link which gcc cannot use
> > Bug#227308: lapack: too many levels of symbolic links on so
> > Bug#224855: atlas2-base-dev: alternatives are broken
> > Merged 224855 225397 227308.
>
> > $ nm -D /usr/lib/liblapack.so
> > nm: /usr/lib/liblapack.so: Too many levels of symbolic links
> >
> > The shared libraries are never used when linking with -llapack or -lblas.
>
> strace is your friend. Is your strace said as follows?
>
> gotom@moog:~> env LANG=C strace -f nm -D /usr/lib/liblapack.so
> ...
> stat64("/usr/lib/liblapack.so", 0xbffff9dc) = -1 ELOOP (Too many levels of symbolic links)
> open("/usr/lib/liblapack.so", O_RDONLY) = -1 ELOOP (Too many levels of symbolic links)
> ...
> gotom@moog:~> env LANG=C cat /usr/lib/liblapack.so
> cat: /usr/lib/liblapack.so: Too many levels of symbolic links
>
> If so, kernel said this symlink has too many levels. Period.
>
> If not, please provide us the complete shell script to generate your
> situation to reappear such trouble on our machine.
>
> Regards,
> -- gotom
>
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: