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>