[Top][All Lists]

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

RE: relinking libraries against libraries installed in DESTDIR (f wd)

From: Winkler, Tomas
Subject: RE: relinking libraries against libraries installed in DESTDIR (f wd)
Date: Tue, 20 Aug 2002 16:04:49 +0300

-----Original Message-----
From: Winkler, Tomas 
Sent: Tuesday, August 20, 2002 4:03 PM
To: 'Tim Mooney'; ',address@hidden'
Subject: RE: relinking libraries against libraries installed in DESTDIR

I have a similar problem and I don't really know to solve it.
Its even problem with libtool-1.2.4-8 (rpm) from redhat which have some
DESTDIR patch. 
When I cross compiling and installing the libraries using DESTDIR
then relink call gcc with -L/usr/lib flags which of course cause linking to
shared libraries.
however ./configure --prefix=$DESTDIR/usr/ works but that is not what I

Thanks for help

Tomas B. Winkler

This may be documented somewhere that I've missed, but there is no `BUGS'
file shipped with libtool and the `TODO' doesn't mention it.

While re-installing a lot of local software from scratch on my
alphaev56-dec-osf5.1 box, I discovered a problem that I've traced back to
libtool.  I switch back and forth between libtool 1.4.2 and 1.4d, depending
what the package I'm trying to build uses, and the problem is present in
both versions.

Basically, if you're building a package that has shared libraries or
modules that depend on other shared libraries in the package, and you
install into a temporary directory for packaging (via DESTDIR=...), when
the shared libraries are relinked during installation, the link will fail
because libtool isn't adding a `-L$DESTDIR$libdir' to the link flags.

This is easiest to see if you try build a package like gettext-0.11.4 or
gdk-pixbuf-0.18.0, each of which has libraries or modules that depend on
other libraries in the same package.

If you just untar, configure, and build those packages and then install
into DESTDIR=/tmp/build they will work *because* each ships with a
`' that has been hacked (in completely different ways) to insert
a `-L' that includes the DESTDIR when relinking the libraries at install

If you rebuild the configure machinery for either of those packages using
stock autoconf/automake/libtool, you'll see that the relink during the
install fails.  As a side note, I don't know what platform Bruno Haible
generated the `gettext-0.11.4.tar.gz' on, but the libtoolize he's using
installed an `' that does a `chmod 777' on the .libs directory
after it creates it.  The vendor that made that change to their custom
libtool should be chastised.

The problem with a stock libtool 1.4.2 or 1.4d not being able to relink
against a shared library's dependencies when using DESTDIR is actually
fairly serious, because

1) If you're building a package for the first time, the link will fail
and if you follow the trail back you'll discover the problem in libtool,
as I did.

2) If you're building a package and there's an older version of the same
package already installed on your system, the link will succeed, but
rather than relinking against the dependency you just installed into
your DESTDIR, your dependent libraries/modules will have linked against
the older version that was installed on the system.  This is sure to
fool and confuse people.

If people need more info, please let me know.

Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

reply via email to

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