mainGNU Libtool - Support: sr #107416, relink with a DESTDIR install...


sr #107416: relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR

Submitter:  Tim Mooney <enchanter>
Submitted:  Fri 02 Jul 2010 07:29:31 PM UTC
Votes: 1
Category:  None Priority:  5 - Normal
Severity:  4 - Important Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup

Tue 07 Jan 2014 06:12:32 PM UTC, comment #2: 

I also hit this bug. As a workaround, enabling fast install (by e.g. passing --enable-fast-install to configure) seems to be enough to solve the problem, since binaries don't need to be relinked during installation.

Alberto Garcia <berto>
Sat 10 Jul 2010 07:04:00 AM UTC, comment #1: 

Yes it is a real problem and it is a Libtool bug.

If you already have a testcase handy, please post it (to the libtool-patches list), preferably as patch against tests/  Thanks.

Ralf Wildenhues <rwild>
Group Member
Fri 02 Jul 2010 07:29:31 PM UTC, original submission:  

This issue affects all versions of libtool from 2.2.10 going back to the initial versions that added support for DESTDIR installs. 

Consider a package "package-1.0", which includes two libraries "liba" and "libb".  liba has a function named "a_1", and libb requires this function and is linked against liba.  package-1.0 gets installed on a system and everyone is happy.

Now package-2.0 comes out.  "liba" now has a new function "a_2", and libb now uses both "a_1" and "a_2".

When compiling package-2.0, libb will correctly link against the liba that's included in package-2.0.

If you just "make install", libb will be correctly relinked, because liba will get installed in the final location first.

HOWEVER, if you do a "DESTDIR" install, the relink step for libb will fail, because libtool doesn't prepend the DESTDIR library directory to the library search path, so when libb is relinked, it finds the liba from package-1.0 that's already installed on the system.  Since the 1.0 version of liba doesn't have function "a_2", the relink fails.

This issue has been reported on the libtool mailing list several times, e.g.

I can find more instances in the mailing lists if necessary, but you get the point.  It's affected a lot of people, and it's a real hassle for people that do software packaging with something like RPM or apt.

Tim Mooney <enchanter>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by berto (Posted a comment)
  • -email is unavailable- added by vadmium
  • -email is unavailable- added by pprindeville (Blighted by this issue in libusb-1.0 and ucd-netsnmp)
  • -email is unavailable- added by draconx
  • -email is unavailable- added by rwild (Posted a comment)
  • -email is unavailable- added by enchanter (Submitted the item)

    There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-22 vadmium Carbon-Copy- Added -email is unavailable-
    2010-07-22 pprindeville Carbon-Copy- Added pprindeville
    2010-07-12 None Carbon-CopyRemoved -email is unavailable- -
    2010-07-12 draconx Carbon-Copy- Added draconx
    2010-07-12 draconx Carbon-Copy- Added -email is unavailable-
    2010-07-10 rwild Severity3 - Normal 4 - Important

    Back to the top

    Powered by Savane 3.13-f762.
    Corresponding source code