libtool relink fails due overriden prefix

["Wesley W. Terpstra" <terpstra@javien.com>]

Another problem I was having is with two libtool libraries that inter-depend.
They are both to be installed in /usr/lib, and just doing a make install
works perfectly, but overriding the prefix variable in the Makefile causes
it to fail.

The libraries are compiled like this:
	libtool c++ -Wall -O2 -g -rpath ${libdir} -o libbar.la \
		bar.lo bar2.lo
	libtool c++ -Wall -O2 -g -rpath ${libdir} -o libfoo.la \
		foo.lo foo2.lo libbar.la

(at the compile stage libtool records the eventual installed path in the .la
files for future use. At this point in the debian build process, libdir
refers to /usr/lib)

They are installed like this:
	libtool install -D libbar.la ${libdir}/libbar.la
	libtool install -D libfoo.la ${libdir}/libfoo.la
	libtool --finish ${libdir}

(at the install stage, debuild has changed what libdir means. It's now
`pwd`/debian/tmp/usr/lib. However, libtool still knows that the eventual
installation path is to be /usr/lib b/c it recorded this in the .la files at
compile time)

The problem is that before installation, libtool actually links libfoo.la
with a --rpath of `pwd`/.libs so that you can debug the libraries without
installing them. ie: loading in libfoo.la will automatically pull in
libbar.la from the correct (uninstalled location) even though this is not in
the normal library install path. This is great. I love libtool.

However, b/c it does this, when I do the libtool install, it has to relink
libfoo.la using -L/usr/lib -lbar to get libfoo.la pointing to the final
location of libbar.la (no --rpath option anymore b/c that would have it
always searching my home directory ;-). In this way, the installed libfoo.la
will pull in the installed libbar.la. This is great. I love libtool.

So, this system is ideal for make, debug, make install. However, the debian
build cycle has one twist that breaks libtool: make, make
prefix=`pwd`/debian/tmp/usr install. This wrecks everything! The problem is
that when libfoo.la is now relinked at install time, libbar.la is not yet in
the final location it will be. Hence, the relink fails, and my install
target dies.

I've found that I can coax libtool into using -L`pwd`/debian/tmp/usr/lib on
the relink command line by including it on the compile line for the library:
	libtool c++ -Wall -O2 -g -L`pwd`/debian/tmp/usr/lib -rpath \
		${libdir} -o libfoo.la foo.lo foo2.lo libbar.la
This way, libtool remembers that as part of the compile command line and later
includes it in the relink command it executes at install. 

However, this hack requires debian-specific stuff in the Makefile. Further,
the directory `pwd`/debian/tmp/usr/lib does not even exist at compile time
when it is first specified. I have no idea what the portability
ramifications of this are. Because the debian directory is to be included in
the upstream source along with stuff to build rpms, I can't have debian-only
cruft in the Makefile.

I assume that there is an accepted solution to this b/c I've been told the
kde libraries have inter-library depends and yet people have packaged them
ok, but I couldn't find where they solved the problem b/c I'm a
debuild/autoconf newbie. :-)

One thing to note, the libtool in woody (1.3.5) is not new enough to do
inter-library depends at all -- I had to get the cvs version of it:
alias cvslibtool="cvs -d:pserver:anoncvs@anoncvs.ffii.org:/var/cvs"

Thanks in advance.

-- 
Wesley W. Terpstra <terpstra@javien.com>
Javien Canada Inc. - Linux Developer