Date: Mon, 13 Mar 2000 17:22:50 +0100 (MET)
From: quinet@xxxxxxxxxx (Raphael Quinet)
> > 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... :-)
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.
> 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.
All that ldconfig -n does is create the links. It doesn't update the
cache. ld.so (at least on Linux) needs the cache:
ld.so(8) ld.so(8)
NAME
ld.so/ld-linux.so - dynamic linker/loader
DESCRIPTION
ld.so loads the shared libraries needed by a program, pre
pares the program to run, and then runs it. Unless
explicitly specified via the -static option to ld during
compilation, all Linux programs are incomplete and require
further linking at run time.
The necessary shared libraries needed by the program are
searched for in the following order
o Using the environment variable LD_LIBRARY_PATH
(LD_AOUT_LIBRARY_PATH for a.out programs). Except
if the executable is a setuid/setgid binary, in
which case it is ignored.
o From the cache file /etc/ld.so.cache which contains
a compiled list of candidate libraries previously
found in the augmented library path.
o In the default path /usr/lib, and then /lib.
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.
My ld.so.conf is correct (if it weren't, running ldconfig wouldn't
solve the problem). I agree that make install should not attempt to
edit ld.so.conf. Botching that will trash the system.
--
Robert Krawitz <rlk@xxxxxxxxxxxx> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx
Project lead for The Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
