GNU bug report logs - #30402
ldconfig confusion

Previous Next

Full log

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 

Previous Next

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