GNU bug report logs - #78321
libtool fails to run ldconfig correctly on GNU/Linux

Previous Next

Full log

View this message in rfc822 format

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 78321 <at> debbugs.gnu.org
Cc: Reuben Thomas <rrt <at> sc3d.org>
Subject: bug#78321: libtool fails to run ldconfig correctly on GNU/Linux
Date: Mon, 12 May 2025 22:08:14 +0300

[Message part 1 (text/plain, inline)]

On 08/05/2025 18:51, Reuben Thomas via bug-libtool via Bug reports for 
the GNU libtool shared library maintenance tool wrote:
> I'm following up on https://lists.gnu.org/archive/html/libtool/2014-05/ 
> msg00024.html <https://lists.gnu.org/archive/html/libtool/2014-05/ 
> msg00024.html>

This was also previously reported in bug#30402 [1].

> I just ran into the same problem: a user reported they had to run 
> `ldconfig` manually after running `[sudo] make install` on one of my 
> projects (Free Recode, formerly GNU Recode). I was surprised, as I 
> thought the autotools ran ldconfig automatically. They do! But on GNU/ 
> Linux systems they run `ldconfig -n`, which does not update the cache, 
> as it implies the -N option. This means that libraries are not found 
> after installation.

Updating the shared library cache from scratch by executing ldconfig in
libtool could cause a lot of headache for developers, so I plan to keep
the usage of 'ldconfig -n' for many GNU/Linux systems. However,
instructions could be clearer for this.

> I checked git, and this usage goes back to the initial commit. I wonder 
> whether something changed since then. Mostly obviously, the -n flag 
> causes ldconfig to process only the directories specified on the command 
> line, which I guess is desirable. I can't see a way to update the cache 
> while retaining this behaviour of -n, but maybe that doesn't make sense?
> 
> Anyway, it seems that either we should simply remove the -n flag from 
> the ldconfig invocation (as on BSD), or document that users will most 
> likely need to run ldconfig themselves after installation (which seems a 
> shame).

After an install, libtool's finish mode might state:

"""
libtool: finish: 
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" 
ldconfig -n /usr/local/lib
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the '-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the 'LD_RUN_PATH' environment variable
     during linking
   - use the '-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to '/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
"""

The following could be added:

"""
After a 'make install' for many GNU/Linux systems, 'ldconfig LIBDIR' may
need to be executed to help locate newly installed libraries, but you
should consult with a system administrator before updating the shared
library cache as this should be done with great care and consideration.
"""

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30402

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.