GNU bug report logs -
#78321
libtool fails to run ldconfig correctly on GNU/Linux
Previous Next
To reply to this bug, email your comments to 78321 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-libtool <at> gnu.org:
bug#78321; Package
libtool.
(Thu, 08 May 2025 15:53:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Reuben Thomas <rrt <at> sc3d.org>:
New bug report received and forwarded. Copy sent to
bug-libtool <at> gnu.org.
(Thu, 08 May 2025 15:53:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#78321; Package
libtool.
(Mon, 12 May 2025 19:09:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 78321 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#78321; Package
libtool.
(Tue, 13 May 2025 09:12:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 78321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 12 May 2025 at 20:08, Ileana Dumitrescu <
ileanadumitrescu95 <at> gmail.com> wrote:
Thanks for the quick reply!
> This was also previously reported in bug#30402 [1]
By me!
Updating the shared library cache from scratch by executing ldconfig in
> libtool could cause a lot of headache for developers,
It would be good to briefly say why it's a problem. (I don't know, and
Debian seems to run ldconfig whenever I install or uninstall a shared
library, so it doesn't seem a big deal at least there.)
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.
> """
>
Again, it would be good if possible to briefly outline potential problems.
Then the informational message is pretty much complete: it will
- explains that users may now need to run ldconfig
- gives them the command to run
-
*says why this might not be a good idea (this bit currently missing!) *
- explains what won't work until the command is run
--
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#78321; Package
libtool.
(Tue, 13 May 2025 15:05:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 78321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Libtool works on many different operating systems, which behave in various
ways. Some OSs will find a new library automatically if it is installed in
the existing configured library paths.
The library installed might not ever be intended to be used by the
currently executing OS because it is part of new distribution builds.
Sometimes libraries are installed privately, using hard-coded run-paths in
the dependent binaries. This is very common when a different version of the
software is to be run than the OS is designed to support.
Expecting a libtool (merely a shell script!) maintainer to write such a
document is unreasonable. It is possible that GNU has such a document
specific to GNU systems.
Bob
On Tue, May 13, 2025, 4:12 AM Reuben Thomas via bug-libtool via Bug reports
for the GNU libtool shared library maintenance tool <bug-libtool <at> gnu.org>
wrote:
> On Mon, 12 May 2025 at 20:08, Ileana Dumitrescu <
> ileanadumitrescu95 <at> gmail.com> wrote:
> Thanks for the quick reply!
>
>
>> This was also previously reported in bug#30402 [1]
>
>
> By me!
>
> Updating the shared library cache from scratch by executing ldconfig in
>> libtool could cause a lot of headache for developers,
>
>
> It would be good to briefly say why it's a problem. (I don't know, and
> Debian seems to run ldconfig whenever I install or uninstall a shared
> library, so it doesn't seem a big deal at least there.)
>
> 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.
>> """
>>
>
> Again, it would be good if possible to briefly outline potential problems.
> Then the informational message is pretty much complete: it will
>
> - explains that users may now need to run ldconfig
> - gives them the command to run
> -
> *says why this might not be a good idea (this bit currently missing!) *
> - explains what won't work until the command is run
>
> --
> https://rrt.sc3d.org
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#78321; Package
libtool.
(Tue, 13 May 2025 15:19:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 78321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 13/05/2025 14:38, Bob Friesenhahn wrote:
> Libtool works on many different operating systems, which behave in
> various ways. Some OSs will find a new library automatically if it is
> installed in the existing configured library paths.
>
> The library installed might not ever be intended to be used by the
> currently executing OS because it is part of new distribution builds.
>
> Sometimes libraries are installed privately, using hard-coded run-paths
> in the dependent binaries. This is very common when a different version
> of the software is to be run than the OS is designed to support.
>
> Expecting a libtool (merely a shell script!) maintainer to write such a
> document is unreasonable. It is possible that GNU has such a document
> specific to GNU systems.
Thank you for your explanation. I think this can be described briefly in
notes.texi to list some of what you outlined above.
> On Tue, May 13, 2025, 4:12 AM Reuben Thomas via bug-libtool via Bug
> reports for the GNU libtool shared library maintenance tool <bug-
> libtool <at> gnu.org <mailto:bug-libtool <at> gnu.org>> wrote:
>
> On Mon, 12 May 2025 at 20:08, Ileana Dumitrescu
> <ileanadumitrescu95 <at> gmail.com <mailto:ileanadumitrescu95 <at> gmail.com>>
> wrote:
> Thanks for the quick reply!
>
>
> This was also previously reported in bug#30402 [1]
>
>
> By me!
>
> Updating the shared library cache from scratch by executing
> ldconfig in
> libtool could cause a lot of headache for developers,
>
>
> It would be good to briefly say why it's a problem. (I don't know,
> and Debian seems to run ldconfig whenever I install or uninstall a
> shared library, so it doesn't seem a big deal at least there.)
>
> 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.
> """
>
>
> Again, it would be good if possible to briefly outline potential
> problems. Then the informational message is pretty much complete: it
> will
>
> * explains that users may now need to run ldconfig
> * gives them the command to run
> * /says why this might not be a good idea *(this bit currently
> missing!)
> */
> * explains what won't work until the command is run
Since libtool is designed to be portable and with the variability for
each system and user needs, I will not add the informational message
to the finishing mode. However, I will add an incomplete list of
issues to libtool's documentation.
--
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)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#78321; Package
libtool.
(Tue, 13 May 2025 18:21:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 78321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 13/05/2025 18:18, Ileana Dumitrescu wrote:
> On 13/05/2025 14:38, Bob Friesenhahn wrote:
>> Libtool works on many different operating systems, which behave in
>> various ways. Some OSs will find a new library automatically if it is
>> installed in the existing configured library paths.
>>
>> The library installed might not ever be intended to be used by the
>> currently executing OS because it is part of new distribution builds.
>>
>> Sometimes libraries are installed privately, using hard-coded run-
>> paths in the dependent binaries. This is very common when a different
>> version of the software is to be run than the OS is designed to support.
>>
>> Expecting a libtool (merely a shell script!) maintainer to write such
>> a document is unreasonable. It is possible that GNU has such a
>> document specific to GNU systems.
>
> Thank you for your explanation. I think this can be described briefly in
> notes.texi to list some of what you outlined above.
>
>> On Tue, May 13, 2025, 4:12 AM Reuben Thomas via bug-libtool via Bug
>> reports for the GNU libtool shared library maintenance tool <bug-
>> libtool <at> gnu.org <mailto:bug-libtool <at> gnu.org>> wrote:
>> * explains that users may now need to run ldconfig
>> * gives them the command to run
>> * /says why this might not be a good idea *(this bit currently
>> missing!)
>> */
>> * explains what won't work until the command is run
>
> Since libtool is designed to be portable and with the variability for
> each system and user needs, I will not add the informational message
> to the finishing mode. However, I will add an incomplete list of
> issues to libtool's documentation.
I have attached a proposed patch for review. I made minor changes to the
explanation Bob provided, but it is largely the same.
--
Ileana Dumitrescu
GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[why-ldconfig-is-needed-after-install-gnu-linux.diff (text/x-patch, attachment)]
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-libtool <at> gnu.org:
bug#78321; Package
libtool.
(Tue, 13 May 2025 20:16:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 78321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 13 May 2025 at 19:20, Ileana Dumitrescu <
ileanadumitrescu95 <at> gmail.com> wrote:
> >
> I have attached a proposed patch for review. I made minor changes to the
> explanation Bob provided, but it is largely the same.
>
Thanks to you both. This text will be a help to developers and users. It's
wild that the GNU system is so complicated that there's no simple solution
(unlike on some other OSes, apparently), but at least with this explanation
we get a heads up and some insight!
--
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Reply sent
to
Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>:
You have taken responsibility.
(Fri, 16 May 2025 16:27:04 GMT)
Full text and
rfc822 format available.
Notification sent
to
Reuben Thomas <rrt <at> sc3d.org>:
bug acknowledged by developer.
(Fri, 16 May 2025 16:27:05 GMT)
Full text and
rfc822 format available.
Message #28 received at 78321-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
A documentation patch has been applied to the development branch [1].
[1]
https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=ad964ee1f5382075b195313d969fb0fe6d83c8e9
--
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)]
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.