This is the mail archive of the
mailing list for the glibc project.
[Bug libc/3378] New: ldconfig handling of links not to soname
- From: "jsm28 at gcc dot gnu dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 18 Oct 2006 00:19:54 -0000
- Subject: [Bug libc/3378] New: ldconfig handling of links not to soname
- Reply-to: sourceware-bugzilla at sourceware dot org
This is related to but not the same as bug 1484. I actually think ldconfig is
probably working as designed here and no change is needed, but I'm not sure.
Suppose that you have a symlink
libfoo.so.1 -> subdir/libbar.so.1.1
where subdir/libbar.so.1.1 is the real file and libbar.so.1 is the SONAME. This
is a variant on the arrangements in
but in this case libfoo.so.1 is an extra compatibility symlink because we
suppose some programs expect that SONAME and libbar.so.1 provides the same
interface. We reach the code
/* If the path the link points to isn't its soname and it is not
.so symlink for ld(1) only, we treat it as a normal file. */
and it treats libfoo.so.1 as if it were an ordinary file like libc-2.5.so. Thus
a symlink libbar.so.1 -> libfoo.so.1 is created and entered in the cache.
The "problem" is that libfoo.so.1 doesn't get entered in the cache under that
name; only the name libbar.so.1. The same applies whatever name or link in the
subdirectory libfoo.so.1 is linked to. This illustrates that there are use
cases where the soname should be entered (the above referenced message) but also
ones where the link itself should be entered under its own name.
Is the case given here something that should actually work? If so, I have a
patch that causes both the link and the soname to be entered in the cache. If
not, perhaps it should be made clearer what cases ldconfig supports.
Summary: ldconfig handling of links not to soname
AssignedTo: drepper at redhat dot com
ReportedBy: jsm28 at gcc dot gnu dot org
CC: glibc-bugs at sources dot redhat dot com
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.