Problem with Libtool-1.5
gschafer at zip.com.au
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
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
- 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
- we now have a mismatch coz the ltmain.sh in the fam tarball is version
1.4 but the aclocal.m4 was created from the 1.5 m4 file. This is broken,
The fix is to run:
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 linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev