[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DESTDIR install and OpenBSD

From: Jacob Meuser
Subject: Re: DESTDIR install and OpenBSD
Date: Mon, 30 Jan 2006 23:14:43 -0800
User-agent: Mutt/1.4.2i

On Tue, Jan 31, 2006 at 04:33:10AM +0100, Ralf Wildenhues wrote:
> 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?  ;-)

because hopefully libtool will soon instruct the linker to use correctly
ordered library search paths.

> > > 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.

it is preferred that someone could install a binary package an any
prefix, and have it work.  for example, the official packages are built
with --prefix=/usr/local, but someone could install a binary openbsd
package into /opt.

> - OpenBSD compiler and/or linker and/or runtime linker are patched to
>   not honor hardcoding arguments (--rpath).

it does honor --rpath

it does honor hardcoded paths in libraries.  for example:

$ objdump -p /usr/local/lib/ | egrep 'NEEDED|RPATH'
  NEEDED      /usr/local/lib/
  NEEDED      /usr/local/lib/
$ objdump -p /usr/local/lib/ | egrep 'NEEDED|RPATH'
  RPATH       /usr/local/lib

and it does honor hardcoded paths in binaries:  for example:

$ objdump -p /usr/local/bin/xmlwf
  RPATH       /usr/local/lib

> - the OpenBSD runtime linker does not honor hardcoded paths in libraries.
> - the OpenBSD runtime linker does not honor hardcoded paths in libraries
>   nor executable.

it does honor both.  the user should be able to do this if he so

> 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.

we don't want full hardcoded paths like /usr/local/lib/
RPATH is not such a big deal.

keeping in mind that we want users to be able to install binary
packages in any prefix, hardcoding paths is really never useful,
at least as far as building packages goes.

there may well be differences in the way we want things to work in
our ports tree, and the way the average user would expect things
to work.

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

AFAICS, this is not currently true.  this may have been the case at
one time, but there has been a bit of work to the runtime linker over
the past few years.

> > > > I have brought this up here before ...
> > > > 
> > > >
> > > 
> > > 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).

huh, that's the only reference I can find as well.


> Cheers,
> Ralf
> _______________________________________________

reply via email to

[Prev in Thread] Current Thread [Next in Thread]