GNU bug report logs - #54928
Libtool 2.4.6 vs. 2.4.7

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54928 in the body.
You can then email your comments to 54928 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: bug-guix <at> gnu.org
Subject: Libtool 2.4.6 vs. 2.4.7
Date: Thu, 14 Apr 2022 11:53:15 +0200

Hello,

is there a good reason to have added libtool-2.4.7 without it replacing
the libtool variable (at version 2.4.6)? I have installed libtool <at> 2.4.7
into my profile, as well as a number of other development tools, and
apparently both libtool versions are now used and are colliding when doing
   autoreconf -vf && ./configure && make
in my project:

make[2]: Verzeichnis „/home/enge/Programme/paritwine/git/src“ wird betreten
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT conversions.lo -MD -MP -MF .deps/conversions.Tpo -c -o conversions.lo conversions.c
libtool: Version mismatch error.  This is libtool 2.4.6, but the
libtool: definition of this LT_INIT comes from libtool 2.4.7.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6
libtool: and run autoconf again.

I can solve the problem by downgrading to libtool <at> 2.4.6 in my profile, but
would argue that this defeats the purpose of adding the new variable at all.

Andreas

Message #8 received at 54928 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: Andreas Enge <andreas <at> enge.fr>, 54928 <at> debbugs.gnu.org
Subject: Re: Libtool 2.4.6 vs. 2.4.7
Date: Thu, 14 Apr 2022 13:29:46 +0200

Am Donnerstag, dem 14.04.2022 um 11:53 +0200 schrieb Andreas Enge:
> Hello,
> 
> is there a good reason to have added libtool-2.4.7 without it
> replacing the libtool variable (at version 2.4.6)? 
libtool causes at least 13802 (mere two thirds of all our packages), so
one might want to ensure that there are no gratuitous bumps when making
new versions of it available :)

> I have installed libtool <at> 2.4.7 into my profile
That is a mistake.

> as well as a number of other development tools
Probably also a mistake.

> [A]pparently both libtool versions are now used
> and are colliding when
> doing
>    autoreconf -vf && ./configure && make
> in my project:
> 
> make[2]: Verzeichnis „/home/enge/Programme/paritwine/git/src“ wird
> betreten
> /bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -
> I.     -g -O2 -MT conversions.lo -MD -MP -MF .deps/conversions.Tpo -c
> -o conversions.lo conversions.c
> libtool: Version mismatch error.  This is libtool 2.4.6, but the
> libtool: definition of this LT_INIT comes from libtool 2.4.7.
> libtool: You should recreate aclocal.m4 with macros from libtool
> 2.4.6
> libtool: and run autoconf again.
> 
> I can solve the problem by downgrading to libtool <at> 2.4.6 in my
> profile, but would argue that this defeats the purpose of adding the
> new variable at all.
I think the problem is caused in the ../libtool symlink, which is
probably not updated to reflect your installation.  This is a known
issue with stale build files, which also happens if you garbage-collect
stuff.  distclean or maintainerclean should solve your issue.  Or you
might just as well delete the symlink manually :)

Cheers

Message #11 received at 54928 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Cc: 54928 <at> debbugs.gnu.org
Subject: Re: Libtool 2.4.6 vs. 2.4.7
Date: Thu, 14 Apr 2022 14:07:02 +0200

Am Thu, Apr 14, 2022 at 01:29:46PM +0200 schrieb Liliana Marie Prikler:
> libtool causes at least 13802 (mere two thirds of all our packages), so
> one might want to ensure that there are no gratuitous bumps when making
> new versions of it available :)

Quite understandable, but if then the new version is added, but unusable,
it can also not be tested.

> > I have installed libtool <at> 2.4.7 into my profile
> That is a mistake.
> > as well as a number of other development tools
> Probably also a mistake.

Could you elaborate why? If you work on a project, it seems necessary
to install development tools (gcc-toolchain, autoconf, automake, make,
texinfo, ...).

> I think the problem is caused in the ../libtool symlink, which is
> probably not updated to reflect your installation.  This is a known
> issue with stale build files, which also happens if you garbage-collect
> stuff.  distclean or maintainerclean should solve your issue.  Or you
> might just as well delete the symlink manually :)

I had already removed it, and the problem persisted. I suppose that
autoreconf or configure created it again in version 2.4.6, and during
make my version 2.4.7 was used instead.

Andreas

Message #16 received at 54928-done <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Cc: 54928-done <at> debbugs.gnu.org
Subject: Re: Libtool 2.4.6 vs. 2.4.7
Date: Thu, 14 Apr 2022 14:22:27 +0200

Am Thu, Apr 14, 2022 at 02:07:02PM +0200 schrieb Andreas Enge:
> I had already removed it, and the problem persisted. I suppose that
> autoreconf or configure created it again in version 2.4.6, and during
> make my version 2.4.7 was used instead.

Actually it is "configure", in my case by calling config/ltmain.sh.
The solution is to remove config/ltmain.sh (actually I removed the
complete config/ subdirectory) and to call "autoreconf -fi" to
recreate it (which also overwrites INSTALL...).

So these are indeed stale files from autotools, somewhat difficult to
spot, since "make distclean" is not enough to remove them.

Anyway, this is not related to Guix, and I am closing the bug.

Andreas

Message #19 received at 54928 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: Andreas Enge <andreas <at> enge.fr>
Cc: 54928 <at> debbugs.gnu.org
Subject: Re: Libtool 2.4.6 vs. 2.4.7
Date: Thu, 14 Apr 2022 14:25:23 +0200

Am Donnerstag, dem 14.04.2022 um 14:07 +0200 schrieb Andreas Enge:
> > > I have installed libtool <at> 2.4.7 into my profile
> > That is a mistake.
> > 
> > > as well as a number of other development tools
> > Probably also a mistake.
> 
> Could you elaborate why? If you work on a project, it seems necessary
> to install development tools (gcc-toolchain, autoconf, automake,
> make, texinfo, ...).
True, but to keep adverse effects resulting from environment mixing to
a minimum, you would typically only use those inside ‘guix environment’
(now ‘guix shell’) and refrain from global installation.  See also a
number of talks suggesting you put a ‘guix.scm’ file into the project
root directory for this very purpose.

> > I think the problem is caused in the ../libtool symlink, which is
> > probably not updated to reflect your installation.  This is a known
> > issue with stale build files, which also happens if you garbage-
> > collect stuff.  distclean or maintainerclean should solve your
> > issue.  Or you might just as well delete the symlink manually :)
> 
> I had already removed it, and the problem persisted. I suppose that
> autoreconf or configure created it again in version 2.4.6, and during
> make my version 2.4.7 was used instead.
I'm not sitting in front of your computer, so I can hardly estimate
what has already been expanded where.  However, the typical flow should
go like this: 
1. autoreconf pulls missing files from your libtool into the auxiliary
directory (typically build-aux).
2. configure detects your libtool and configures it according to the
configuration options you pass.
3. make invokes libtool -- if make detects the Makefile itself to be
old, it might restart from 2.
In any case, the error points towards autoreconf not using 2.4.6, but
2.4.7 as base, i.e. an error in step (1).  Maybe you forgot to run it?
Also, never run autoreconf without -v, it stands for "very important".

As a general rule, the GNU build system does not provide a tooclean
target for make.

Cheers

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.