helpGNU 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

Submitted by:  Tim Mooney <enchanter>
Submitted on:  Fri 02 Jul 2010 07:29:31 PM UTC  
Votes:  1  
Category: NonePriority: 5 - Normal
Severity: 4 - ImportantStatus: None
Privacy: PublicAssigned to: None
Open/Closed: OpenOperating System: None

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


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>
Project Administrator
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 File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 1 encouragement so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 22 Feb 2012 01:22:28 PM UTCvadmiumCarbon-Copy-=>Added -unavailable-
    Thu 22 Jul 2010 08:17:38 PM UTCpprindevilleCarbon-Copy-=>Added pprindeville
    Mon 12 Jul 2010 02:03:05 PM UTCNoneCarbon-CopyRemoved -unavailable-=>-
    Mon 12 Jul 2010 02:02:58 PM UTCdraconxCarbon-Copy-=>Added draconx
    Mon 12 Jul 2010 02:02:18 PM UTCdraconxCarbon-Copy-=>Added -unavailable-
    Sat 10 Jul 2010 07:04:00 AM UTCrwildSeverity3 - Normal=>4 - Important

    Back to the top

    Powered by Savane 3.1-cleanup1