On Sun, 12 Mar 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz <[EMAIL PROTECTED]> wrote:
> > 1. libtool should make sure that the libraries are found anyway (unless
> > moved). ld.so.cache is only that, a cache
> >
> > Well, then gimp.m4 does the wrong thing, since after I install a new
> > version of the Gimp I can't use gimp.m4 within autoconf to test for
>
> Ah, now I see the problem. Hmm... I guess shared libraries are still
> largely unexplored for the many ways to do it "right" :(
Hmmm... Strange, because it works for me. Does that happen with the
latest version of the Gimp, or with a version older than 1.1.17?
> > Like I said: this should be run as part of the installation procedure
> > "on Elf-based systems, at any rate".
>
> But "Elf" and "ldconfig" are not too related to each other.
Yup! I have an elf-based Solaris system that does not know anything
about ldconfig... :-)
> However, the solution is easy: somebody who wants it should write the
> necessary autoconf and makefile magic to detect wether ldconfig exists and
> (at installation time) wether it should be run (uid == 0 is a good hint).
First, I would like to be sure that it happens with the latest version
of the Gimp. I just checked the source for 1.1.17 and 1.1.18, and both
of them are distributed with a version of libtool that includes the
following on Linux systems:
finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
This is run immediately after installing each library in $libdir. So
at least the recent versions of the Gimp _do_ run ldconfig as part of
"make install" and you should not have any problems.
On the other hand, maybe you are having a problem with ld.so.conf, not
with ld.so.cache. The latter is updated by ldconfig, but the former
can only be modified by hand. I think that it would be wrong for a
tool to attempt to modify ld.so.conf automatically, because the order
of the directories is important and some modifications could break the
whole system.
-Raphael
