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

Previous Next

Package: libtool;

Reported by: Reuben Thomas <rrt <at> sc3d.org>

Date: Thu, 8 May 2025 15:53:02 UTC

Severity: normal

Done: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>

Full log


View this message in rfc822 format

From: Reuben Thomas <rrt <at> sc3d.org>
To: 78321 <at> debbugs.gnu.org
Subject: bug#78321: libtool fails to run ldconfig correctly on GNU/Linux
Date: Thu, 8 May 2025 16:51:50 +0100
[Message part 1 (text/plain, inline)]
I'm following up on
https://lists.gnu.org/archive/html/libtool/2014-05/msg00024.html

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.

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).

-- 
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]

This bug report was last modified 28 days ago.

Previous Next


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