Date: Mon, 13 Mar 2000 17:22:50 +0100 (MET)
   From: [EMAIL PROTECTED] (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. (at least on Linux) needs the cache:                                       

NAME - dynamic linker/loader

DESCRIPTION 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/ 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, not
   with  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 automatically, because the order
   of the directories is important and some modifications could break the
   whole system.

My is correct (if it weren't, running ldconfig wouldn't
solve the problem).  I agree that make install should not attempt to
edit  Botching that will trash the system.

Robert Krawitz <[EMAIL PROTECTED]>

Tall Clubs International  -- or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for The Gimp Print --

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Reply via email to