Subject: Re: static vs. dynamic runtime linking, and silly 'ld -L' breakage
To: Jaromir Dolecek <jdolecek@NetBSD.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 01/29/2005 16:17:13
[ On Saturday, January 29, 2005 at 10:42:19 (+0100), Jaromir Dolecek wrote: ]
> Subject: Re: static vs. dynamic runtime linking, and silly 'ld -L' breakage
>
> ld.so.conf hurts for same reasons why it's wrong to use LD_LIBRARY_PATH.
That's only because ld.so.conf doesn't implement a primary feature of
the _original_ LD_LIBRARY_PATH from UNIX System V Release 4.
> In order to work in POLA fashion, the path specified in LD_LIBRARY_PATH
> or ld.so.conf must be searched first.
The original SVR4 ELF implementation did not have that restriction:
The environment variable LD_LIBRARY_PATH may be used to specify
library search directories. In the most general case it will
contain two directory lists separated by a semicolon:
dirlist1;dirlist2
Thus if 'ld' is called with the following occurences of -L:
ld ... -Lpath1 ... -Lpath2 ... -lx
then the search path ordering for the library x (libx.so or
libx.a) is:
dirlist1 path1 ... pathn dirlist2 LIBPATH
LD_LIBRARY_PATH is also used to specify library search
directories to the dynamic linker at run time.
("LIBPATH" is the default system search list, "usually /usr/ccs/lib:/usr/lib")
(of course SVR4 didn't have anything even like /etc/ld.so.conf either)
> Not depending on ld.so.conf is actually more flexible, and using
> compiled-in rpaths indeed 'just works'. That's why it's default
> since ELF switch.
Well if ld.so.conf also had a way to specify an "early list" and a "late
list", just as the original LD_LIBRARY_PATH implementation did, then it
would in fact be actually more flexible. :-)
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>