GNU bug report logs - #30402
ldconfig confusion

Previous Next

To reply to this bug, email your comments to 30402 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-libtool <at> gnu.org
Subject: ldconfig confusion
Date: Fri, 9 Feb 2018 13:10:43 +0000

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

I just noticed that on my GNU/Linux system (and on stock Ubuntu 14.04,
which is where I first encountered this), I need to run

ldconfig

after installing shared libraries built with libtool. I was confused at
first, because libtool itself runs

ldconfig -n $(libdir)

But I guess because this does not update the cache, it doesn't make the
library available.

I hadn't noticed this before because normally when I'm building code on my
own system, I install it in my home directory, with a suitable setting of
LD_LIBRARY_PATH; no ldconfig call is needed.

The libtool manual says:

  7. The install 'Makefile' target should warn the package installer to
     set the proper environment variables ('LD_LIBRARY_PATH' or
     equivalent), or run 'ldconfig'.

But libtool does not warn me that I (may) need to run ldconfig.

In 1997, commit 7f9b4e50 for libtool version 0.6b, the way of running
ldconfig was changed from running without "-n" to running with "-n". The
ChangeLog entry (I think it is for the same change, though it occurs months
later in commit 41ced2149):

+       * ltconfig.in (finish_cmds): Change back to using `ldconfig -n'.
+       This makes Linux behave like other systems, which is more in line
+       with what libtool needs.

I'm not sure what it means by "what libtool needs" here, but perhaps 20
years later it's worth reconsidering this (and simply removing the -n flag
on Linux again)? Or, if it's not possible, at least warn the user that it
may be necessary to run ldconfig.

I'm using libtool version 2.4.6, but I can't see that anything has changed
in current git in this respect.​​

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 30402 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#30402: ldconfig confusion
Date: Fri, 9 Feb 2018 10:57:31 -0600 (CST)

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

On Fri, 9 Feb 2018, Reuben Thomas wrote:
>
> But libtool does not warn me that I (may) need to run ldconfig.
>
> In 1997, commit 7f9b4e50 for libtool version 0.6b, the way of running
> ldconfig was changed from running without "-n" to running with "-n". The
> ChangeLog entry (I think it is for the same change, though it occurs months
> later in commit 41ced2149):
>
> +       * ltconfig.in (finish_cmds): Change back to using `ldconfig -n'.
> +       This makes Linux behave like other systems, which is more in line
> +       with what libtool needs.
>
> I'm not sure what it means by "what libtool needs" here, but perhaps 20
> years later it's worth reconsidering this (and simply removing the -n flag
> on Linux again)? Or, if it's not possible, at least warn the user that it
> may be necessary to run ldconfig.
>
> I'm using libtool version 2.4.6, but I can't see that anything has changed
> in current git in this respect.​​

This feels like a big dangerous change to me, especially since the 
current mode of operation has been in place for 20 years.  Should 
installing a package result in refreshing the configuration for the 
whole system, causing changes unrelated to the package?

The installation prefix used is important since it might be into a 
directory already configured via /etc/ld.so.conf or it might be some 
directory that ldconfig does not know about.

I see that Ubuntu provides special handling for /usr/local via 
/etc/ld.so.conf.d/libc.conf:

% cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

% cat /etc/ld.so.conf.d/libc.conf
# libc default configuration
/usr/local/lib

If one installs into a prefix that ldconfig does not already know 
about, then it seems that additional ldconfig configuration should be 
required in order for shared libraries installed there to work 
correctly.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: 30402 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#30402: ldconfig confusion
Date: Fri, 9 Feb 2018 17:07:29 +0000

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

On 9 February 2018 at 16:57, Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
wrote:

> This feels like a big dangerous change to me, especially since the current
> mode of operation has been in place for 20 years.  Should installing a
> package result in refreshing the configuration for the whole system,
> causing changes unrelated to the package?
>

​It should update the cache, yes, because otherwise the user has to do that
anyway, or the newly-installed library won't work.

I don't see any way with Linux ldconfig to do this in a more restrictive
way.​


> The installation prefix used is important since it might be into a
> directory already configured via /etc/ld.so.conf or it might be some
> directory that ldconfig does not know about.
>
> I see that Ubuntu provides special handling for /usr/local via
> /etc/ld.so.conf.d/libc.conf:
>
> % cat /etc/ld.so.conf
> include /etc/ld.so.conf.d/*.conf
>
> % cat /etc/ld.so.conf.d/libc.conf
> # libc default configuration
> /usr/local/lib
>
> If one installs into a prefix that ldconfig does not already know about,
> then it seems that additional ldconfig configuration should be required in
> order for shared libraries installed there to work correctly.
>

​I was installing into /usr/local/lib. My system does indeed have this
(default) configuration.​

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #20 received at 30402 <at> debbugs.gnu.org (full text, mbox):

From: Roumen Petrov <bugtrack <at> roumenpetrov.info>
To: 30402 <at> debbugs.gnu.org
Cc: Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#30402: ldconfig confusion
Date: Fri, 09 Feb 2018 22:41:06 +0200

Reuben Thomas wrote:
> I just noticed that on my GNU/Linux system (and on stock Ubuntu 14.04,
> which is where I first encountered this), I need to run
>
> ldconfig
>
> after installing shared libraries built with libtool. I was confused at
> first, because libtool itself runs
>
> ldconfig -n $(libdir)
>
> But I guess because this does not update the cache, it doesn't make the
> library available.

I'm not sure.

I just run one of my tests - build of binary with shared library and and 
installation into one system default paths for shared libraries.
Result:
- ldconfig -p does not show new library
- ldd binary shows library
- binary is executed properly

Next step is upgrade of library and execution of binary - result shows 
that is used updated library.

I'm not familiar with ldconfig cache and until now I did not have issue 
with installation in development environment.

In production package manager is responsible to swap correctly library 
on the fly.



[SNIP]

Regards,
Roumen Petrov

Message #23 received at 30402 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Roumen Petrov <bugtrack <at> roumenpetrov.info>
Cc: 30402 <at> debbugs.gnu.org
Subject: Re: bug#30402: ldconfig confusion
Date: Fri, 9 Feb 2018 21:12:17 +0000

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

On 9 February 2018 at 20:41, Roumen Petrov <bugtrack <at> roumenpetrov.info>
wrote:

> Reuben Thomas wrote:
>
>> I just noticed that on my GNU/Linux system (and on stock Ubuntu 14.04,
>> which is where I first encountered this), I need to run
>>
>> ldconfig
>>
>> after installing shared libraries built with libtool. I was confused at
>> first, because libtool itself runs
>>
>> ldconfig -n $(libdir)
>>
>> But I guess because this does not update the cache, it doesn't make the
>> library available.
>>
>
> I'm not sure.
>
> I just run one of my tests - build of binary with shared library and and
> installation into one system default paths for shared libraries.
> Result:
> - ldconfig -p does not show new library
> - ldd binary shows library
> - binary is executed properly
>

​
​Thanks for this.

In my tests, ldd binary did not show the library, and the binary was not
executed properly. Also, the library did not show up with ldconfig -p, but
of course that is the expected result after running only ldconfig -n.

​I obtained these results both on my personal Ubuntu 16.04 system (but of
course there could be some oddity with the configuration), and, more
convincingly, with fresh Ubuntu 14.04 as used on Travis CI (I had my Travis
build run ldd on the binary, and the library was shown as not found;
running "sudo ldconfig" made the library found).

So, it could be some oddity (so far, it looks like a bug) with Ubuntu
systems in their default configuration.​

Does anyone have any further suggestions for things I can test? In any
case, it looks like a bug report to Ubuntu may be warranted; Roumen, could
you possibly tell us what sort of GNU/Linux system you are using?​

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #26 received at 30402 <at> debbugs.gnu.org (full text, mbox):

From: Roumen Petrov <bugtrack <at> roumenpetrov.info>
To: 30402 <at> debbugs.gnu.org
Subject: Re: bug#30402: ldconfig confusion
Date: Sat, 10 Feb 2018 11:29:21 +0200

Hi Reuben,

Reuben Thomas wrote:
> On 9 February 2018 at 20:41, Roumen Petrov <bugtrack <at> roumenpetrov.info>
> wrote:
>
>> Reuben Thomas wrote:
>>
>>> I just noticed that on my GNU/Linux system (and on stock Ubuntu 14.04,
>>> which is where I first encountered this), I need to run
>>>
>>> ldconfig
>>>
>>> after installing shared libraries built with libtool. I was confused at
>>> first, because libtool itself runs
>>>
>>> ldconfig -n $(libdir)
>>>
>>> But I guess because this does not update the cache, it doesn't make the
>>> library available.
>>>
>>
>> I'm not sure.
>>
>> I just run one of my tests - build of binary with shared library and and
>> installation into one system default paths for shared libraries.
>> Result:
>> - ldconfig -p does not show new library
>> - ldd binary shows library
>> - binary is executed properly
>>
>
> ​
> ​Thanks for this.
>
> In my tests, ldd binary did not show the library, and the binary was not
> executed properly. Also, the library did not show up with ldconfig -p, but
> of course that is the expected result after running only ldconfig -n.
>
> ​I obtained these results both on my personal Ubuntu 16.04 system (but of
> course there could be some oddity with the configuration), and, more
> convincingly, with fresh Ubuntu 14.04 as used on Travis CI (I had my Travis
> build run ldd on the binary, and the library was shown as not found;
> running "sudo ldconfig" made the library found).
>
> So, it could be some oddity (so far, it looks like a bug) with Ubuntu
> systems in their default configuration.​
>
> Does anyone have any further suggestions for things I can test? In any
> case, it looks like a bug report to Ubuntu may be warranted; Roumen, could
> you possibly tell us what sort of GNU/Linux system you are using?​
>


Test was performed on "Slackware 14.2 (64-bits) + multilib".
$ ldd --version
ldd (GNU libc) 2.23
Copyright (C) 2016 Free Software Foundation, Inc.
...

For tests of libtool functionality I always use by builds of libtool as 
is, i.e. FSF version without any vendor patches.


You case is quite interesting and I did test on centos 6. Same result. 
Environment details:
$ ldd --version
ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
...
$ libtool --version
ltmain.sh (GNU libtool) 2.2.6b
...


Regards,
Roumen


P.S. Mostly off-topic:
Installation into system paths is not so easy process. The fact that 
above test pass does not mean that I recommend use of make 
install(libtool --mode install) for installation into system paths.
Usual scenario is (1) configure, (2) make, (3) make install.
If installation is into system paths third step has to be replaced with 
(3.1) make install DESTDIR=.... (3.2) packaging with package manager(PM) 
and (3.3) installation by PM.

I did not succeed to find publication that could provide more details 
how to replace manually libraries on the fly. For instance GNU C library 
question highlights issue
https://sourceware.org/glibc/wiki/FAQ#How_do_I_install_all_of_the_GNU_C_Library_project_libraries_that_I_just_built.3F 

Message #31 received at 30402-done <at> debbugs.gnu.org (full text, mbox):

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 30402-done <at> debbugs.gnu.org
Cc: Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#30402: ldconfig confusion
Date: Fri, 16 May 2025 19:28:34 +0300

[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)]

Previous Next

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