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

Bug#1111805: ld.so.conf settings prefer /lib over /usr/lib (drop /lib from ld.so.conf entirely?)



On 2025-09-15 13:49, Michael Biebl wrote:
> Am 14.09.25 um 21:19 schrieb Aurelien Jarno:
> > On 2025-09-14 21:14, Michael Biebl wrote:
> > > Am 14.09.25 um 15:25 schrieb Michael Biebl:
> > > 
> > > Just curious: Have you rebuilt the whole archive?
> > 
> > Not me, but yes :) There are only a couple of failures not yet reported
> > (still investigating), but they are totally different kind of failures.
> > 
> 
> It appears "ncl" is also affected by this change [1], basically all packages
> that link against libgtcp.
> 
> Checking with objdump, they all have
>   NEEDED               libgctp-2.0.0.so
> 
> I.e. the dependency is not including the SOVERSION. Notably it's the only
> NEEDED entry which ends with .so.
> 
> The setup of libgctp is also a bit special:
> 
> > lrwxrwxrwx 1 root root     18 Sep  5 13:31 /usr/lib/x86_64-linux-gnu/libgctp-2.0.0.so -> libgctp-2.so.2.0.0
> > lrwxrwxrwx 1 root root     18 Sep  5 13:31 /usr/lib/x86_64-linux-gnu/libgctp-2.0.0.so.2 -> libgctp-2.so.2.0.0
> > -rw-r--r-- 1 root root 141224 Sep  5 13:31 /usr/lib/x86_64-linux-gnu/libgctp-2.so.2.0.0
> > lrwxrwxrwx 1 root root     18 Sep  5 13:31 /usr/lib/x86_64-linux-gnu/libgctp.so -> libgctp-2.so.2.0.0
> 
> 
> So this could either be a bug in dpkg-shlibdeps, libgctp or the three
> packages linking against libgctp.
> 
> 
> Aurelien, wdyt?

Yes, the symlinks look quite strange and probably a big source of 
problem... At least less tested code paths.

That said, I think what matter at the end is the soname encoded in the 
elf file:

| $ readelf --dynamic /usr/lib/x86_64-linux-gnu/libgctp.so  | grep SONAME
|  0x000000000000000e (SONAME)             Library soname: [libgctp-2.0.0.so]

Which seems consistent with the NEEDED in hdf-eos5:

| $ readelf --dynamic debian/libhe5-hdfeos0t64/usr/lib/x86_64-linux-gnu/libhe5_hdfeos.so.0.0.0 | grep NEEDED
|  0x0000000000000001 (NEEDED)             Shared library: [libgctp-2.0.0.so]
|  0x0000000000000001 (NEEDED)             Shared library: [libhdf5_serial_hl.so.310]
|  0x0000000000000001 (NEEDED)             Shared library: [libhdf5_serial.so.310]
|  0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
|  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Looking at deb-shlibs(5) it seems this strange soname format is 
supported:

| SONAME FORMATS
|        The SONAME formats supported are:
| 
|            name.so.version
| 
|        and
| 
|            name-version.so
| 
|        where name is usually prefixed by lib.
| 
|        The former tends to be used by shared libraries with stable
|        interfaces.  The latter by shared libraries with unstable
|        interfaces, where the whole version becomes part of the SONAME
|        and needs to be specified in full when linking against those
|        libraries.

And this seems consistent with the shlibs file:

| $ cat /var/lib/dpkg/info/libgctp-2.0.0\:amd64.shlibs
| libgctp 2.0.0 libgctp-2.0.0 (>= 2.0.0)

Also all of that doesn't explain the behaviour of dpkg-shlibdeps 
depending if a symlink is used or not in ld.so.conf. Intuitively I would 
say it should not have any impact and should either fail or pass (not 
100% sure of my analysis above) independently of that configuration.

Interestingly, you don't need both paths in ld.so.conf, things works as 
long as you have at least /lib/x86_64-linux-gnu.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

Attachment: signature.asc
Description: PGP signature


Reply to: