Newsgroups: comp.windows.x
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!fernwood!lia!steve
From: steve@lia (Stephen Williams)
Subject: Re: Sun shared libs - openwin vs MIT R4
Message-ID: <1991May14.223605.8518@lia>
Reply-To: steve@lia.com (Stephen Williams)
Organization: Litton/Integrated Automation, Alameda, California
References: <9105090143.AA02124@lightning.McRCIM.McGill.EDU> <785@sunpix.East.Sun.COM> <OLSON.91May10234038@lear.juliet.ll.mit.edu>
Date: Tue, 14 May 91 22:36:05 GMT

In article <OLSON.91May10234038@lear.juliet.ll.mit.edu> olson@juliet.ll.mit.edu ( Steve Olson) writes:
>In article <785@sunpix.East.Sun.COM> matthew@sunpix.East.Sun.COM (Matthew Stier - Sun Visualization Products) writes:
>   In article <9105090143.AA02124@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes:
>   >Did you try -Bstatic? :-)
>
>   ENVIRONMENT
>	LD_LIBRARY_PATH
>	     A colon-separated  list  of  directories  in  which  to
>	     search  for  libraries  specified  with  the -l option.
>	     Similar   to    the    PATH    environment    variable.
>	     LD_LIBRARY_PATH  also  affects library searching during
>	     execution-time loading, causing the search to use first
>	     those  directories  found  in the environment variable,
>	     then any  directories  specified  by  -L  options,  and
>	     finally   the   standard   directories   /usr/lib   and
>	     /usr/local/lib.  NOTE:  when  running  a  set-user-  or
>	     set-group-ID   program,  ld.so  will  only  search  for
>	     libraries  in  directories  it  "trusts",   which   are
>	     /usr/lib,  /usr/5lib,  /usr/local/lib,  and  any direc-
>	     tories specified within the executable as a  result  of
>	     -L options given when the executable was constructed.
>
>     address  space.  The algorithm by which such files are found
>     mimics that used when ld is run, and like ld, can be  influ-
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     enced  by  the setting of LD_LIBRARY_PATH and any -L options
>     specified to ld when the program was built.
>


I feel I should nip this in the bud.  A snippet from ld(1), that describes
link time loading:

     ld searches for the desired object file through  a  list  of
     directories  specified  by -L options, the environment vari-
     able LD_LIBRARY_PATH, and  finally,  the  built-in  list  of
     standard    library   directories:   /lib,   /usr/lib,   and
     /usr/local/lib.


... and farther on in the man page, describing "Execution time" loading:

     address  space.  The algorithm by which such files are found
     mimics that used when ld is run, and like ld, can be  influ-
     enced  by  the setting of LD_LIBRARY_PATH and any -L options
     specified to ld when the program was built.

However, the following contradicts the combination of these snippets:

          LD_LIBRARY_PATH  also  affects library searching during
          execution-time loading, causing the search to use first
          those  directories  found  in the environment variable,
          then any  directories  specified  by  -L  options,  and
          finally   the   standard   directories   /usr/lib   and
          /usr/local/lib.

It has been my experience that at link time libraries are searched
in the order:

	-L directories first,
	LD_LIBRARY_PATH last

while at run time they are search in the order:

	LD_LIBRARY_PATH
	-L directories

This is very much in contridiction to the second snippet,  and causes
X people much stress when trying to use both X and OpenLook tools,
and I think it is clear now why that is.

--Steve
steve@lia.com