I read the FAQ as well, and disagree that the way it is being done is
an improvement.  We have a bunch of Solaris 2.X machines around here which
basically implement the same functionality we have with our ELF system, and
on our main Oracle server, we have LD_LIBRARY_PATH variabbles with
screes-full of data.  This is because the good folks at Oracle, and the
other third-party library builders, didn't think anyone would want to use
things in different locations than they compiled into their binary search
paths.  The ELF system works well enough on integrated environments where
things are going to be put in a standard location, or where one has the
ability to relink object files, but it falls apart immediately when you buy
binary-only products where the builder never conceived of anyone using anything
other than /usr/local and plan to run them in a large complex environment
with a myriad of other pieces of software.  LD_LIBRARY_PATH is a crutch, in
my opinion, and a huge thorn in my side, but one we have to use
continuously to make our Solaris 2.X systems do the right thing.  On the
other hand, our SunOS based systems, as well as our Older NetBSD systems,
work quite nicely with highly expanded ld.so.conf files.  Users don't have
to remember to set funky environment variables, and we don't have to
admonish them to be sure to use the right global initialization files when
they start mucking with their standard dot files.
	I, for one, would like to see an ldconfig mechanism come back to the
NetBSD ELF implementation, with the option of not using it.  In short, I
agree with the question in the FAQ about *REALLY *REALLY *REALLY wanting
ldconfig.  My real-life experience using ELF and not having it says it's a
good thing, adds flexibility for the end-system administrator, and takes
the burden off the vendor, who wouldn't take the responsibility anyway, of
thinking of every path one might choose to use for squirreling a library or
two.
-Brian
On Aug 12,  6:43pm, Arthur wrote:
} Subject: Re: ld.so.conf?
} On Wed, 11 Aug 1999 22:50:01 -0400 (EDT), mcmahill@mtl.mit.edu wrote:
} 
} >> I don't see any ld.so.conf or ldconfig.  All I see is ld.elf_so in
} >> /usr/libexec.
} >
} >please see http://www.netbsd.org/Documentation/elf.html and in particular
} >http://www.netbsd.org/Documentation/elf.html#ldconfig which answers the
} >question "There is no ldconfig! No /etc/ld.so.conf!"
} 
} 
} Thanks for the pointer.  I see where it says:
} 
} > The primary directory locating mechanism is the ``rpath'' search list contained
} > within the executable image. This search list is set with the -rpath directive
} > to ld(1). The Posix syntax for passing ld options through the compiler front
} > end is 
} >
} >        -Wl,option,option,... 
} 
} I was trying to build Midnight Commander, so I tweaked the Makefile to
} also use:
} 
}      -Wl,-rpath /usr/local/lib
} 
} and it finds the shared library now, so I suppose my guess at the
} correct syntax was OK.  The space after -rpath worries me though.  I
} wonder how it knows to put /usr/local/lib together with -rpath?
} 
>-- End of excerpt from Arthur