[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 29 Sep 2000 11:29:36 -0500
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
albert chin (address@hidden)