update on libtool, ldconfig

Felix Salfelder <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.