Re: why is ldconfig needed after installation
The problem here is that *-n* implies *-N* which instructs *ldconfig* not to rebuild the cache. > > *-n*Only process directories specified on the command line. Don't process > the trusted directories (*/lib* and */usr/lib*) nor those specified in > */etc/ld.so.conf*. Implies *-N*. > *-N*Don't rebuild the cache. Unless *-X* is also specified, links are > still updated. The following files exist in */usr/local/lib*: - file *libmy.so.0.0.0* - symlink *libmy.so.0 -> libmy.so.0.0.0* - symlink *libmy.so** -> libmy.so.0.0.0* When I call *ldconfig* with the verbose flag manually after *make install* (cache is still not updated), it does not seem to detect all of them: $ ldconfig -v -n /usr/local/lib /usr/local/lib: libmy.so.0 -> libmy.so.0.0.0 In my opinion, *ldconfig* option *-n* should *not* imply *-N* or at least update the cache according to the changes (added, modified and deleted files). ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: why is ldconfig needed after installation
On 05/26/2014 05:07 PM, Peter Johansson wrote: Hm, there is nothing in my 'Makefile.in' that mentions --mode=finish. Is there any reason for that or is it a automake bug? I investigated this a bit further. 'libtool --mode=finish' is indeed called and it calls 'ldconfig -n /usr/local/lib' but that doesn't update the cache as I want. Instead I have $ ldconfig -p | grep yat libyat.so.8 (libc6,x86-64) = /usr/local/lib/libyat.so.8 libyat.so.7 (libc6,x86-64) = /usr/local/lib/libyat.so.7 libyat.so.6 (libc6,x86-64) = /usr/local/lib/libyat.so.6 libyat.so.5 (libc6,x86-64) = /usr/local/lib/libyat.so.5 libyat.so (libc6,x86-64) = /usr/local/lib/libyat.so but I just installed libyat.so.9. If I instead call $ sudo ldconfig /usr/local/lib $ ldconfig -p | grep yat libyat.so.9 (libc6,x86-64) = /usr/local/lib/libyat.so.9 libyat.so.8 (libc6,x86-64) = /usr/local/lib/libyat.so.8 libyat.so.7 (libc6,x86-64) = /usr/local/lib/libyat.so.7 libyat.so.6 (libc6,x86-64) = /usr/local/lib/libyat.so.6 libyat.so.5 (libc6,x86-64) = /usr/local/lib/libyat.so.5 libyat.so (libc6,x86-64) = /usr/local/lib/libyat.so in other words, it works as I want if I call 'lconfig /usr/local/lib' but not if I call 'ldconfig -n /usr/local/lib'. What does the -n switch? The man page says: *-n* /Only process directories specified on the command line. Don't process the trusted directories (/lib and /usr/lib) nor those specified in /etc/ld.so.conf. Implies -N. / IIUC, that means that the cache is not rebuilt because I have '/usr/local/lib' in '/etc/ld.so.conf'. Why is ldconfig called with -n? I did some digging and found that it's been like that since beginning of time, or at least since v0.6a. Cheers, -- Peter Johansson ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: why is ldconfig needed after installation
On 05/26/2014 11:07 AM, Russ Allbery wrote:
ldconfig has to be run because the dynamic linker maintains a cache of
available libraries that has to be updated. libtool does this when run
with libtool --mode=finish on the installation directory. I'm not sure if
it does this when it thinks the directory isn't listed in the system
library search path, though.
Hm, there is nothing in my 'Makefile.in' that mentions --mode=finish. Is
there any reason for that or is it a automake bug?
install-libLTLIBRARIES: $(lib_LTLIBRARIES)
@$(NORMAL_INSTALL)
@list='$(lib_LTLIBRARIES)'; test -n $(libdir) || list=; \
list2=; for p in $$list; do \
if test -f $$p; then \
list2=$$list2 $$p; \
else :; fi; \
done; \
test -z $$list2 || { \
echo $(MKDIR_P) '$(DESTDIR)$(libdir)'; \
$(MKDIR_P) $(DESTDIR)$(libdir) || exit 1; \
echo $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
--mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2
'$(DESTDIR)$(libdir)'; \
$(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install
$(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 $(DESTDIR)$(libdir); \
}
Cheers,
--
Peter Johansson
___
https://lists.gnu.org/mailman/listinfo/libtool
why is ldconfig needed after installation
Hi libtoolers, I just installed a library with libtool (via automake generated rules) and when trying to use the lib I get this: error while loading shared libraries: libyat.so.9 which is going away if I issue sudo ldconfig /us/local/lib My question is why is that even needed, as I thought libtool already did that. No? I've noticed the message at installation ---8 Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---8 So I've followed the last bit there and added a file '/etc/ld.so.conf.d/local.conf' that contains '/usr/local/lib' to make the runtime linker aware of '/usr/local/lib'. Yet I need to do a ldconfig manually every time I install something. Am I missing something or doing something wrong? This is on RHEL6. Cheers, Peter This is on RHEL6 and I've added -- Peter Johansson ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: why is ldconfig needed after installation
Peter Johansson troj...@gmail.com writes: I just installed a library with libtool (via automake generated rules) and when trying to use the lib I get this: error while loading shared libraries: libyat.so.9 which is going away if I issue sudo ldconfig /us/local/lib My question is why is that even needed, as I thought libtool already did that. No? ldconfig has to be run because the dynamic linker maintains a cache of available libraries that has to be updated. libtool does this when run with libtool --mode=finish on the installation directory. I'm not sure if it does this when it thinks the directory isn't listed in the system library search path, though. -- Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/ ___ https://lists.gnu.org/mailman/listinfo/libtool
