SYSROOT/DESTDIR (was Re: static vs. dynamic linking)

[Howard Chu]

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.

> *time passes*
> http://lists.gnu.org/archive/html/libtool-patches/2005-06/msg00161.html
> Oh, you asked before.  Why not rather fix your patch than rewrite from
> scratch?

Have we got an exhaustive list of problems related to this particular 
issue? This is definitely a pain my side; I've been maintaining custom 
hacks for our own builds for a couple of years now and it's getting 
mighty old.

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

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

It seems like a pretty simple thing to get working, without any negative 
side effects.
--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/