Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!mit-eddie!xn.ll.mit.edu!xn!olson
From: olson@juliet.ll.mit.edu ( Steve Olson)
Newsgroups: comp.windows.x
Subject: Re: Sun shared libs - openwin vs MIT R4
Message-ID: <OLSON.91May10234038@lear.juliet.ll.mit.edu>
Date: 11 May 91 04:40:38 GMT
References: <9105090143.AA02124@lightning.McRCIM.McGill.EDU>
	<785@sunpix.East.Sun.COM>
Sender: usenet@xn.ll.mit.edu
Organization: M.I.T. Lincoln Lab - Group 43
Lines: 60
In-Reply-To: matthew@sunpix.East.Sun.COM's message of 10 May 91 13:52:36 GMT

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? :-)

   Best suggestion, if the user has the source to his program. Gets around the
   shared library problems all together. 

Gee, who needs all that disk space?  Hey Sun, whats the point of shared
libraries in the first place?  Best suggestion:  make OW work better
with the rest of the world.

   As to the order of execution by the dynamic linker, I submit the following
   manpage clipping, to support the statement, that the linker is acting properly.

   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.

Um, that only *part* of relevant man page sections.  *Before* you see
the previous, you'll see the following.  These are from the 4.1.1 version,
the 4.0.3 version is unambigiously wrong.

     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.

     When ld.so is given control on program startup, it finds all
     .so  files  specified  when the program was constructed (and
     all .so's on which they depend), and  loads  them  into  the
     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.

   -- 
   Matthew Lee Stier    (mstier@east.Sun.COM)   |
   Sun Microsystems ---  RTP, NC  27709-3447    |     "Wisconsin   Escapee"
   uucp:  sun!mstier or mcnc!rti!sunpix!matthew |
   phone: (919) 469-8300 fax: (919) 460-8355    |
--
-- Steve Olson
-- MIT Lincoln Laboratory
-- olson@juliet.ll.mit.edu
--