Problem with Libtool-1.5

Greg Schafer gschafer at
Tue May 27 23:53:12 PDT 2003

On Wed, May 28, 2003 at 01:01:34AM -0400, Jeremy Utley wrote:
> This post from the libtool bug mailing list might shed some additional
> light on the problem:
> I don't pretend to understand all of it, but there is a reported bug in
> Libtool 1.5 when a package ships with a earlier private version of
> Libtool.

It's urm, sort of relevant :-)

> I'm not necessarily suggesting dropping back...but this problem,
> according to Dagmar, affects more than just fam.  I haven't seriously
> scoured my system for affected libs, and most things appear to be
> working normally.  But, since I know a lot of the "GNU Experts" like you
> and Ryan and all don't frequent the *-support lists, I figured it might
> be a useful thing to get cross-posted.

Ok, I've reproduced the problem and found the fix.

The breakage is caused by the rerunning of the autotools. What is happening
is this:-

 - the BLFS patch touches various autotools files that force them to be
 - part of this rerunning involves running aclocal

 - aclocal recreates aclocal.m4 (it's programmed to look at
   /usr/share/aclocal which, lo & behold, contains libtool.m4 from the
   libtool-1.5 package!)

 - we now have a mismatch coz the in the fam tarball is version
   1.4 but the aclocal.m4 was created from the 1.5 m4 file. This is broken,
   broken, broken!

The fix is to run:

  libtoolize --force

imediately after applying the fam patch.

The whole concept of relying on the autotools to rebuild the necessary files
is a BROKEN idea! At least from our package builders POV. It's certainly a
nice feature for developers actively devloping code, but for us pkg
builders, it cannot work reliably. BLFS must address this!

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list