What's the current status of libtool support for $ORIGIN? The docs don't mention it. In the list I find:
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=%24ORIGIN&submit=Search%21&idxname=libtool&max=20&result=normal&sort=date%3Alate As of 2009 the answer is "no support": http://lists.gnu.org/archive/html/libtool/2009-02/msg00035.html 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": https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html (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 projects). 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? Nico -- _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
