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.


Reply via email to