Relocatable libraries with libtool--can I do it?

[Paul Smith]

Hi all.  I'm having a severe problem with libtool-ized packages, of
which there are more and more these days, in my environment.  I'm
wondering if anyone here can suggest how I should proceed; whether
there's something in libtool that will help me, or whether libtool needs
enhancements, or what.

My environment involves running in an x86 host running Linux, and
cross-compiling everything for a different target.  A few extra things
about this are (a) that we do not use chroot or any similar technology,
and (b) the entire thing needs to be completely relocatable at any
time.

You can probably already see where I'm going to have problems with
libtool.  One saving grace (for me) is that the target environment is
also always running Linux (on PPC, or MIPS, or whatever) and I'm always
using GCC.  So, I know that I will always have a fully-featured
compiler/linker/dynamic loader/etc. environment.


My environment basically works like this: each "environment" is called
an image.  Each image consists of a complete filesystem hierarchy for a
standard (stripped down) distribution for a given target.  The physical
root of this hierarchy (at build time) is no "/" of course; it's defined
in the environment variable ROOT.

So, I might have ROOT=/tmp/ppc-image, then I would have
/tmp/ppc-image/bin, /tmp/ppc-image/usr/bin, /tmp/ppc-image/usr/include,
/tmp/ppc-image/lib, etc. etc.

But I need to be able to copy that entire image to another location, set
ROOT to that location, and cross-compile code using that image in that
new location.

A final note is that while I need to move these images around at build
time, at _RUNTIME_ they will always be installed where the root of the
image is at "/".  So, runtime linker paths like /lib are correct and
acceptable.


For basic compilation we use a wrapper for the cross-compiler; the
wrapper takes the options passed in and adds to the end other -L,
-isystem, or whatever flags are needed for GCC to do the right thing
based on the value of $ROOT.  That works fine for normal, non-libtool
configure packages; I can just use things like:

    export ROOT=/tmp/ppc-image
    ./configure --prefix=/usr CC=ppc-gcc CXX=ppc-g++
    make
    make install DESTDIR="$ROOT"

This almost always works, these days.


The problem is that libtool-generated libraries are not relocatable: for
example the .la files have hardcoded paths in them and no way to reset
them.  That means that after I relocate the image, any package I compile
that tries to use those .la files to get the proper environment will
fail miserably.

It seems like the right answer would be for the .la files to have
knowledge of ROOT or DESTDIR, or some other variable like LIBTOOL_ROOT
or something, and automatically prepend that value to the appropriate
pathnames for finding libraries _AT BUILD TIME_, without impacting the
paths set to find libraries _AT RUNTIME_.

Does this seem correct?  Or am I missing something else?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>   HASMAT: HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.