Re: EXTRA_LDFLAGS

[Albert Chin-A-Young]

On Fri, Sep 29, 2000 at 09:20:47AM -0400, Thomas E. Dickey wrote:
> On Fri, 29 Sep 2000, Albert Chin-A-Young wrote:
> 
> > On Fri, Sep 29, 2000 at 05:46:01AM -0400, Thomas Dickey wrote:
> > > On Fri, Sep 29, 2000 at 12:55:37AM -0500, Albert Chin-A-Young wrote:
> > > >   2. The value of EXTRA_LDFLAGS if --enable-rpath is given for Solaris 
> > > > is:
> > > >      EXTRA_LDFLAGS="-R ../lib:\$(libdir) $EXTRA_LDFLAGS"
> > > > 
> > > >      Is this really a wise thing? I might need some correcting on this 
> > > > but
> > > ...
> > > >      I know why ../lib is chosen but I dislike it.
> > > 
> > > iirc, the reason why is that it won't link otherwise (yes, it is ugly, but
> > > given the number of people who try to run the applications without 
> > > installing
> > > them, it seems the best solution).  But it is restrictive (doesn't really
> > > allow rearrangement of the pieces after linking).
> > 
> > Are there any security implications? That's my main concern.
> 
> I recall seeing a comment to that effect (I know that some loaders will,
> some won't use _your_ ../lib versus the executable's ../lib).  Perhaps I
> should investigate that (thanks).

FYI, Solaris 2.7 and HP-UX 10.20 honor "../lib". This is most likely
only for user binaries though. I doubt suid binaries would.

However, to solve this "right", you need to understand how the linker
works on each system. For example, Solaris allows you to use -R [path]
where [path] is *non-existent*. Under HP-UX, +b [path] requires [path]
to *exist*. So, then, the only way to get the correct runtime path in
HP-UX binaries is to re-create the binary at install time after the
library has been installed and link against the install library path
(libtool does this). Even worse, HP-UX adds [path] from -L[path] in the
runtime list of library search paths. So, "-L../lib -lncurses" would
add "../lib/libncurses.sl" to the runtime list of library paths under
HP-UX.

-- 
albert chin (address@hidden)