[Top][All Lists]

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

Support for $ORIGIN, again?

From: Nico Williams
Subject: Support for $ORIGIN, again?
Date: Mon, 31 Mar 2014 18:56:15 -0500

What's the current status of libtool support for $ORIGIN?  The docs
don't mention it.  In the list I find:

As of 2009 the answer is "no support":

Regarding "one of the first questions": all modern Solaris, Linux, and
BSDs support $ORIGIN with equivalent semantics.

OS X supports a similar concept, expanding a token named "@loader_path":

(It's incorrectly described as an environment variable.  Further
searching reveals that it's very much like $ORIGIN.)

So it seems like time for libtool to support $ORIGIN.

There are, of course, still issues w.r.t. message catalog directories
(for bindtextdomain), but arguably these should be fixed there using
$ORIGIN too.  And apps can always use dladdr() (where supported) to
obtain their load path and get the same effect as $ORIGIN.  I believe
these are cleanly separable issues, with the first and foremost issue
being support of $ORIGIN in libtool.

Using the GNU relocatable modules is not really an answer for a
variety of reasons not the least of which is the GPL (not every open
source project wants it, but note that libtool can be used for non-GPL

As to desired semantics:

a) the libtool caller should specify the $ORIGIN/whatever path to be
added to the rpath (e.g., libtool -rpath $ORIGIN/../lib ...),

b) libtool should have an option to NOT add directories to the rpath
of the target (because there's no reason to add any beyond whatever
$ORIGIN-based ones the caller wanted).

I suppose that libtool could help construct $ORIGIN-based rpaths, but
since libtool would have to understand the install layout... that
would be extra complexity.

Thoughts?  Would patches for this be welcomed?


reply via email to

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