On Tue, 14 Mar 2000, Robert L Krawitz <[EMAIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED] (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.