Skip site navigation (1) Skip section navigation (2)

Re: more multibyte/After TGL...

From: Larry Rosenman <ler(at)lerctr(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: more multibyte/After TGL...
Date: 2000-10-29 14:33:43
Message-ID: 20001029083342.A6831@lerami.lerctr.org (view raw or flat)
Thread:
Lists: pgsql-hackers
* Peter Eisentraut <peter_e(at)gmx(dot)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
   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      peter_e(at)gmx(dot)net       http://yi.org/peter-e/

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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-10-29 14:57:56
Subject: Re: Handler for plpgsql out of date?
Previous:From: Martin A. MarquesDate: 2000-10-29 14:27:16
Subject: BAR now and with 7.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group