On Sun, 12 Mar 2000, Marc Lehmann <marc@xxxxxxxx> wrote: > On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz <rlk@xxxxxxxxxxxx> 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
