Re: SYSROOT/DESTDIR

[Ralf Wildenhues]

Hi Howard,

* Howard Chu wrote on Tue, Sep 27, 2005 at 12:01:22PM CEST:
> Ralf Wildenhues wrote:
> >We have better support for sysroot and/or DESTDIR on our TODO list.
> >Why don't you help us improve and fix libtool?  That is bound to be
> >a lot less work.

> >http://lists.gnu.org/archive/html/libtool-patches/2005-06/msg00161.html
> 
> Have we got an exhaustive list of problems related to this particular 
> issue?

Well, probably not exhaustive, but I've made notes here and there.
I'll try to collect things together, and hope to post more in a couple
of days.  Above link lists some issues.

Incidentally, the TODO list already cites an email by you :)
http://lists.gnu.org/archive/html/libtool/2004-11/msg00307.html
and Daniel reed once described what people might want when they use
DESTDIR (although we might not allow all of that):
http://lists.gnu.org/archive/html/libtool-patches/2005-01/msg00203.html
Under linux, accessing hardwired /etc/ld.so.conf needs adapting:
http://lists.gnu.org/archive/html/libtool/2004-11/msg00366.html
The issue of normalizing paths is unfortunately hard/impossible, and:
http://lists.gnu.org/archive/html/libtool/2005-01/msg00210.html
is broken ($A/foo/../$B is not equal to $A/$B if foo is a symlink
going not exactly one level down).

> First of all, my objective - other folks may have their own objectives 
> different than this: Build a suite of software that uses shared 
> libraries, such that any embedded runpaths only reflect the ultimate 
> install path (e.g. /opt/foo/lib) and not any of the build paths (e.g. 
> ~/src/project1/blah).

Hmm, yes, the idea is good.  But at the time you configure and build a
package which relies on an already-installed library (with its correct
final embedded runpath, but found under a different location _now_),
you'll have to start dancing anyway.

> So far this issue is relevant to us on AIX, HPUX, Linux, and Solaris. In 
> all cases, it's possible to set an environment variable (LIBPATH, 
> SHLIB_PATH, or LD_LIBRARY_PATH, respectively) to tell the runtime linker 
> where to really look, regardless of any embedded paths. So my preferred 
> behavior would be for build paths to never be embedded in the object 
> files (this also eliminates any need for relinking).

That'll work for the runtime linker, but not for the link editor
(in all cases).

OTOH: which of these systems have linkers with sysroot support?  I
believe proper support on capable systems is still worth a lot even if
we can't realize this on all systems.

> Since libtool will 
> generate wrapper scripts that setup the proper environment for 
> executables anyway, I don't see any problem with achieving this. 
> Currently libtool tries to be "clever" and always prepends build paths 
> to any explicitly provided -R/-rpath options, and I usually comment that 
> bit out of libtool in our builds.

Hmm.  It might be reasonable to add this as a link-time option or so.
Disabling this for uninstalled libraries/programs sounds much safer
than doing so for installed ones.

> It seems like a pretty simple thing to get working, without any negative 
> side effects.

I don't overlook this completely yet, but having this as an option
(not the default) is bound to be rather safe.

One of my ideas was to support basically two modes of operation:
1) You have a package you install somewhere; that is not the final
destination (thus you use DESTDIR), but it will basically operate
on the build system.  But other components (deplibs, config files)
you access may be found outside of the $DESTDIR (or inside?).
2) Your host system has nothing in common with / and all lives under
some subtree, let's call it SYSROOT.  Cross compilation is an example
of this.

Following this, and maybe for safety calling the necessary variables
$LT_DESTDIR and $LT_SYSROOT, and presuming we have this information
available already at configure time we can go about changing libtool
incrementally.   Making these two match with the non-prefixed ones
is then trivial, but if it works against ones habits, possible to
keep them separated.

Cheers,
Ralf