Re: DESTDIR install and OpenBSD

[Ralf Wildenhues]

Hi Jacob,

* Jacob Meuser wrote on Fri, Jan 27, 2006 at 04:16:22AM CET:
> On Thu, Jan 26, 2006 at 02:27:42PM +0100, Ralf Wildenhues wrote:
> > * Jacob Meuser wrote on Thu, Jan 26, 2006 at 03:57:03AM CET:
> > > 
> > > this is a long standing problem, actually.  it is related to
> > > hardcode_direct=yes.  there is a workaround in OpenBSD's libtool port
> > > for about 1.5 years:
> > 
> > It's a workaround.
> 
> agreed.  it is a relatively cheap "fix".
> 
> >  If `$libdir/$linklib' happens to actually exist but
> > be the wrong thing, it fails to work around; 
> 
> true.  however, this is really close to the same problem as already
> exists wrt library search paths.  so it's not creating any more of
> a problem than already exists.

Agreed.

> will need to be reexamined soon though :)

Why?  Because we keep mumbling about not linking against indirect
deplibs?  ;-)

> > if it does not exist,
> > libtool fails to add hardcoding for the respective library, resulting in
> > execution startup failure.
> 
> it's not a problem on OpenBSD, because OpenBSD doesn't rely on the
> path being hardcoded.  in fact, it it preferred that the paths are
> not hardcoded.

I'd like this statement clarified a bit, to one (or more) of these:
- OpenBSD developers prefer to not have any hardcoded paths in libraries.
- OpenBSD developers prefer to not have any hardcoded paths in executables.
- OpenBSD compiler and/or linker and/or runtime linker are patched to
  not honor hardcoding arguments (--rpath).
- the OpenBSD runtime linker does not honor hardcoded paths in libraries.
- the OpenBSD runtime linker does not honor hardcoded paths in libraries
  nor executable.

I see a long-term goal in making useful deviations from default libtool
behavior available with a standardized interface, but have libtool
behave more similar across systems by default; i.e., since we hardcode
non-system directories by default everywhere where it's useful, we
should do it on OpenBSD as well, so end-users get what they can rightly
expect; but we should have a switch to change to other useful behaviors,
as far as consistent semantics can be specified.  Usually, the most
difficult issue is the definition of such consistent semantics (see the
indirect deplibs issue for example) and the writing of good tests to
expose these.

IIRC OpenBSD will not use the indirect deplibs issue because its runtime
linker does not load DT_NEEDED dependencies.  Right?

> > > I have brought this up here before ...
> > > 
> > > http://www.archivum.info/address@hidden/2004-11/msg00481.html
> > 
> > You brought it up there, but the cited thread actually deals with a
> > slightly different problem, IIRC.
> 
> yes.  I did bring it up on it's own at some point, but I did not
> find that message in the archives (didn't look all that hard).

AFAICS it's the only time that's been posted (since I started reading
libtool lists).

Cheers,
Ralf