On Tue, 14 Mar 2000, Robert L Krawitz <rlk@xxxxxxxxxxxx> wrote: > From: quinet@xxxxxxxxxx (Raphael Quinet) > > Yup! I have an elf-based Solaris system that does not know anything > about ldconfig... :-) > > It's happened with at least 1.1.17 and 1.1.18. The fact that you're > using Solaris explains why you don't have a problem. Hmmm... I should have said that I _also_ have an elf-based Solaris system. My development machine at home is a PC running Linux (based on SuSE 6.3, as I described in another message). I did not have any problems on my Linux system, but this is probably because I am so used to running ldconfig after installing anything that I did not even remember that I had to use it. ;-) > All that ldconfig -n does is create the links. It doesn't update the > cache. ld.so (at least on Linux) needs the cache: You are right, I should have thought about why libtool uses the "-n" option. I think that libtool runs "ldconfig -n" because this is the only option that can be used safely, since it does not require more permissions than the ones for installing the libraries. Libtool already prints a message telling the user to run "ldconfig" or "ldconfig -v" after installing something, so any user who watches the installation process should know what to do. The Gimp Makefile (not libtool) could have an additional call to "ldconfig" or "-(PATH="\$PATH:/sbin" ldconfig) > /dev/null" immediately after calling "$(LIBTOOL) --mode=install". But the installation rules in the Makefiles are generated by autoconf/automake and it could be a bit tricky to hack them. -Raphael
