[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: from debian-mentors: libtool relink fails due overriden prefix

From: Wesley W. Terpstra
Subject: Fwd: from debian-mentors: libtool relink fails due overriden prefix
Date: Fri, 20 Oct 2000 13:13:12 -0600
User-agent: Mutt/1.2.5i

Sorry for cross-mailing, but this message was quite lengthy and I didn't
want to have to write it all out again when I'd already carefully crafted an
accurate description of the problem.

I know you people don't care at all about debian packaging, but thought that
perhaps libtool has a mechanism for dealing with situations like this. 

Basically, the issue from a libtool point of view is that I have two
libraries where one depends on the other. Normal building in the source
directory works great. It can be debugged wonderfully due to the --rpath.
When installed directly into the destination, the relink does the right
thing and makes the libraries use the final location.

However, when packaging a library one often doesn't actually install straight
onto the root filesystem. In this case, I want the libraries to have exactly
the same bytes as if they'd be installed right into the root filesystem with
all the associated symlinks, etc. However, I can't actually install them
into the root filesystem b/c I'm merely packaging the library. They are
installed to a packaging directory which I intend to tar up and extract onto
the root filesystem at a later date.

How, if at all, does libtool allow a user to accomplish this?

Just doing a libtool install will fail b/c relinking the dependent library
at install time uses -L/usr/lib -lbar when the was not actually
installed to /usr/lib but an packaging directory.


----- Forwarded message from "Wesley W. Terpstra" <address@hidden> -----

Date: Fri, 20 Oct 2000 10:56:16 -0600
To: address@hidden
Subject: libtool relink fails due overriden prefix
From: "Wesley W. Terpstra" <address@hidden>

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 \
                bar.lo bar2.lo
        libtool c++ -Wall -O2 -g -rpath ${libdir} -o \
                foo.lo foo2.lo

(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 ${libdir}/
        libtool install -D ${libdir}/
        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
with a --rpath of `pwd`/.libs so that you can debug the libraries without
installing them. ie: loading in will automatically pull in 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 using -L/usr/lib -lbar to get pointing to the final
location of (no --rpath option anymore b/c that would have it
always searching my home directory ;-). In this way, the installed
will pull in the installed 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 is now relinked at install time, 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 foo.lo foo2.lo
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:address@hidden:/var/cvs"

Thanks in advance.

Wesley W. Terpstra <address@hidden>
Javien Canada Inc. - Linux Developer

----- End forwarded message -----

Wesley W. Terpstra <address@hidden>
Javien Canada Inc. - Linux Developer

Attachment: pgpBNBgsVzPvu.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]