From xemacs-m  Wed May 28 13:55:16 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id NAA14750
	for <xemacs-beta@xemacs.org>; Wed, 28 May 1997 13:55:15 -0500 (CDT)
Received: from Canada.Sun.COM ([129.155.5.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA21179 for <xemacs-beta@xemacs.org>; Wed, 28 May 1997 12:11:35 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA28114; Wed, 28 May 1997 14:54:13 -0400
Received: from verve.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id OAA17292; Wed, 28 May 1997 14:54:40 -0400
Received: by verve.canada.sun.com (SMI-8.6/SMI-SVR4)
	id OAA23345; Wed, 28 May 1997 14:54:46 -0400
Date: Wed, 28 May 1997 14:54:46 -0400
Message-Id: <199705281854.OAA23345@verve.canada.sun.com>
From: Georg Nikodym <georgn@Canada.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: `-R' on Solaris
In-Reply-To: <199705281401.KAA00826@anthem.CNRI.Reston.Va.US>
References: <kigu3jom7k5.fsf@jagor.srce.hr>
	<199705281401.KAA00826@anthem.CNRI.Reston.Va.US>
X-Mailer: VM 6.31 under 20.3 XEmacs Lucid (beta2)
Reply-To: georgn@Canada.Sun.COM
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo

>>>>> "BAW" == Barry A Warsaw <bwarsaw@CNRI.Reston.VA.US> writes:

 BAW> Some of the Solaris gurus on this list might have a better
 BAW> explanation of what's going on.  I'm just relating observations
 BAW> from the trenches. :-)

I guess that's my cue.

First let me say that the linker is part of the system that's _REALLY_
well documented (Linker and Libraries Guide) but we programmers tend
to be illiterate...

Here's how -L and -R work.

-L tells the link editor (ld) where to look for .so's and .a's
The LD_LIBRARY_PATH env variable does the same.  Directories added the 
path by -L take precedence.

So, if LD_LIBRARY_PATH=/tmp then for ld to honour the args "-L/var/tmp
foo.o -lx -ly -lz" it will look in /var/tmp:/tmp:/usr/lib for libx,
liby, and libz.

The resultant binary has a dynamic dependency on lib[xyz] but no
location information (path) is encoded.

-R tells the link editor (ld) to add the run path that gets encoded
into an ELF object (dynamic executable or shared object).  The
LD_RUN_PATH env variable does the same.

So, if LD_RUN_PATH=/tmp then ld with the args "-R/var/tmp
-L/var/tmp foo.o -lx -ly -lz" will look only in /var/tmp for
lib[xyz] but will encode /var/tmp:/tmp in the run path of the binary.

At run time, the runtime linker will use binary's run path before
examining the LD_LIBRARY_PATH environment variable to find dynamic
dependencies.

So, in the first example, assume that lib[xyz] live in /var/tmp.  The
program will only run with LD_LIBRARY_PATH=/var/tmp.

The second example, will run without an LD_LIBRARY_PATH...  If
lib[xyz] lived in /foo, however, then an LD_LIBRARY_PATH=/foo would be 
required to run...

Clear as mud.  Ultimate flexibility leading to ultimate chaos.

