[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnucap-devel] update on libtool, ldconfig

From: Felix Salfelder
Subject: [Gnucap-devel] update on libtool, ldconfig
Date: Sat, 10 Oct 2015 17:29:34 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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: 
> 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
$ gnucap
... ... 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/, 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  
          libraries in the default library paths are skipped.  Libraries 
installed in
          hardware  capability  directories  (see  below)  are  preferred  to   

and LDCONFIG(8) says

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

in particular, /etc/ 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, not automake nor libtool, as
you might have suspected. need to investigate...

have fun

reply via email to

[Prev in Thread] Current Thread [Next in Thread]