Libtool 2.4.6 vs. 2.4.7

  • Done
  • quality assurance status badge
Details
2 participants
  • Andreas Enge
  • Liliana Marie Prikler
Owner
unassigned
Submitted by
Andreas Enge
Severity
normal

Debbugs page

Andreas Enge wrote 3 years ago
(address . bug-guix@gnu.org)
YlfvC4syUwT+NazZ@jurong
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@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@2.4.6 in my profile, but
would argue that this defeats the purpose of adding the new variable at all.

Andreas
Liliana Marie Prikler wrote 3 years ago
58e51b928f8ede76cfbf106cccace12ef72539b0.camel@ist.tugraz.at
Am Donnerstag, dem 14.04.2022 um 11:53 +0200 schrieb Andreas Enge:
Toggle quote (4 lines)
> 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 :)

Toggle quote (1 lines)
> I have installed libtool@2.4.7 into my profile
That is a mistake.

Toggle quote (1 lines)
> as well as a number of other development tools
Probably also a mistake.

Toggle quote (20 lines)
> [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@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
Andreas Enge wrote 3 years ago
(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)(address . 54928@debbugs.gnu.org)
YlgOZqog/H2MKjxN@jurong
Am Thu, Apr 14, 2022 at 01:29:46PM +0200 schrieb Liliana Marie Prikler:
Toggle quote (4 lines)
> 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.

Toggle quote (5 lines)
> > I have installed libtool@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, ...).

Toggle quote (6 lines)
> 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
Andreas Enge wrote 3 years ago
(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)(address . 54928-done@debbugs.gnu.org)
YlgSA3K7BwaZt2iW@jurong
Am Thu, Apr 14, 2022 at 02:07:02PM +0200 schrieb Andreas Enge:
Toggle quote (4 lines)
> 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
Closed
Liliana Marie Prikler wrote 3 years ago
(name . Andreas Enge)(address . andreas@enge.fr)(address . 54928@debbugs.gnu.org)
b1e483ca81870d16b0a9593e0d1090fceb9097ac.camel@ist.tugraz.at
Am Donnerstag, dem 14.04.2022 um 14:07 +0200 schrieb Andreas Enge:
Toggle quote (9 lines)
> > > I have installed libtool@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.

Toggle quote (9 lines)
> > 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
?
Your comment

This issue is archived.

To comment on this conversation send an email to 54928@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 54928
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help