On Mon, 2 Apr 2001, T@W wrote:

> I "always" learned that in order to guarantee a succesfull build from
> source (esp.3rd party binaries and packages being able to find the right
> paths), I need to put the paths in ld.so.conf.

That's not quite true. On a.out (i.e. 1.4.3/i386) ld.so.conf affects
run-time behavior. It never had any effect on linking. By the way, the
paths that used to be in /etc/ld.so.conf, now need to be in
/emul/etc/ld.so.conf. /etc/ld.so.conf, for ELF, does something else.

> E.g. if certain sources (from packages or thirdparty) don't have the path
> coded in and on build are looking for files in libdirs besides the emul (if
> they don't have the search patch coded in), do I  "need" to use the
> ld.so.conf or is there a magic override in a mk file to autocorrect when
> compiling from such sources?

Many third-party packages do indeed fail to code the path correctly.
The simple formula, which we do all over "pkgsrc", is everywhere
there's an "-L/usr/foo/lib", add a corresponding "-Wl,-R/usr/foo/lib".
You can often do this without modifying the package's makefiles by
adding the arguments to "LDFLAGS". "pkgsrc" automatically adds
"LDFLAGS=-Wl,-R/usr/pkg/lib -Wl,-R/usr/X11R6/lib" to the environment
of every "make build" and "make configure", which catches the vast
majority of cases, but patches are sometimes necessary, still.

> >But even on ELF, you can still use LD_LIBRARY_PATH if necessary.
> >
>
> Even when the ldconfig-1.5 doesn't recognize the path set in
> /etc/ld.so.conf?

In a word, yes. You can't, as a matter of fact, link any a.out
binaries on 1.5/i386 _at_ _all_. "ldconfig" and
"/emul/aout/etc/ld.so.conf" only come into play when when you're
running binaries built before you upgraded. So if you must run an
incorrectly built ELF binary, LD_LIBRARY_PATH is your only option.

LD_LIBRARY_PATH is also convenient to let you run against shared
libraries that haven't been installed (yet).


Frederick