* Peter Eisentraut <[EMAIL PROTECTED]> [001029 05:48]:
> Larry Rosenman writes:
>
> > YUP, it's LD_LIBRARY_PATH.
>
> That's odd. On my system (and on all others that I've heard of that have
> it) this only affects the runtime linker, not the "ld" linker.
Maybe, but here is the tail end of ld's man page:
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 occurrences of -L:
ld . . . -Lpath1 . . . -Lpathn . . . -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. That is, if LD_LIBRARY_PATH exists
in
the environment, the dynamic linker will search the directories it
names before its default directory for shared objects to be linked
with the program at execution.
Additionally, the environment variable LD_RUN_PATH (which also
contains a directory list) may be used to specify library search
directories to the dynamic linker. If present and not empty, it is
passed to the dynamic linker by ld via data stored in the output
object file. LD_RUN_PATH is ignored if building a shared object.
The
paths it specifies are searched by the dynamic linker before those
specified by LD_LIBRARY_PATH. LD_RUN_PATH is obsolete. Its use is
discouraged in favor of the -R option to ld. If -R is specified,
LD_RUN_PATH is ignored.
Files
libx.so
libraries
libx.a
libraries
a.out
output file
LIBPATH
usually /usr/ccs/lib:/usr/lib
/usr/lib/local/locale/LC_MESSAGES/uxcds
language-specific message file [See LANG on environ(5).]
References
a.out(4), ar(4), as(1), cc(1), elfmark(1), end(3C), exec(2),
exit(2)
Notices
Through its options, the link editor gives users great flexibility;
however, those who use the -M mapfile option must assume some added
responsibilities. Use of this feature is strongly discouraged.
ld should be invoked directly only if -r is used to create a
relocatable object to be used in a later link. Creation of an
executable or shared object should be done through the CC or cc
command. The CC command must be used if any input object files
contain
C++ code.
_________________________________________________________________
30 January 1998
M-) 2000 The Santa Cruz Operation, Inc. All rights reserved.
UnixWare/OpenServer Development Kit 7.1.1b Feature Supplement
See also ld(1bsd)
can't open
can't open
$ $
So, at least for the UDK FS, we probably need to walk the
LD_LIBRARY_PATH and cleanse it of any libraries that contain OUR libs.
>
> > We need to make sure that the BUILD Unsets it...
>
> Are you sure that this can't lead to failures if a program run during the
> build requires this to be set. (Something like tclsh comes to
> mind.) Seems like something you ought to do manually.
But could we do the above to cleanse it of our stuff?
>
> --
> Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
