Re: more multibyte/After TGL...

* Peter Eisentraut <peter_e@gmx.net> [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
librarysearch 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
objectsto be linked  with the program at execution.    Additionally, the environment variable LD_RUN_PATH (which also
containsa 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
buildinga 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
mustassume some added  responsibilities. Use of this feature is strongly discouraged.    ld should be invoked directly
onlyif -r is used to create a  relocatable object to be used in a later link. Creation of an  executable or shared
objectshould 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
TheSanta Cruz Operation, Inc. All rights reserved.  UnixWare/OpenServer Development Kit 7.1.1b Feature Supplement  See
alsold(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      peter_e@gmx.net       http://yi.org/peter-e/

-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749