[Gnucap-devel] update on libtool, ldconfig

[Felix Salfelder]

On Mon, Feb 09, 2015 at 09:37:53PM -0500, al davis wrote:
> What does not work in the current autotools branch?  There's an 
> easy bug that  the m4 directory is missing, then when I make and 
> make install just taking defaults and run it, it says:
> "gnucap: error while loading shared libraries: libgnucap.so.0: 
> cannot open shared object file: No such file or directory"

Hi Al.

i think i now have a better explanation for this one. first of all i can
reproduce it (i assume that you are on linux or some similar OS).

$ rm /usr/local/lib/libgnucap*
as root# ldconfig
$ ./configure; make install # prefix is /usr/local
$ which gnucap
/usr/local/bin/gnucap
$ gnucap
...  libgnucap.so.0 ... No such file or directory
as root# ldconfig
$ gnucap
... now works.

what is happening? this is described in LD.SO(8)

       If a library dependency does not contain a slash, then it is searched
       for  in  the  following order:
[..]
       o  From the cache file /etc/ld.so.cache, which contains  a  compiled  
list  of
          candidate  libraries  previously  found in the augmented library 
path.  If,
          however, the  binary  was  linked  with  the  -z  nodeflib  linker  
option,
          libraries in the default library paths are skipped.  Libraries 
installed in
          hardware  capability  directories  (see  below)  are  preferred  to   
other
          libraries.
[..]

and LDCONFIG(8) says

       ldconfig  creates  the  necessary  links  and  cache to the most recent 
shared
       libraries found in the directories specified on the command line, in the 
 file
       /etc/ld.so.conf,  and  in  the  trusted  directories (/lib and 
/usr/lib).  The
       cache is used by the run-time linker, ld.so or ld-linux.so.   ldconfig  
checks
       the header and filenames of the libraries it encounters when determining 
which
       versions should have their links updated.

in particular, /etc/ld.so.conf is authoritative (and used by libtool the
way i described in my previous mail on this). and refreshing the cache
(manually) seems to be mandatory.

there is something curious however (on my system): if I put the
libraries to /usr/lib/x86_64-linux-gnu/, gnucap *hangs* on startup, then
starts correctly. there is some weird (undocumented?) magic going on.

the essence is this: the problem is ld.so, not automake nor libtool, as
you might have suspected. need to investigate...

have fun
felix