[blfs-dev] MesaLib-10.4.3 make failed for libtool-2.4.2, solution is simple

Fernando de Oliveira famobr at yahoo.com.br
Mon Jan 26 06:22:00 PST 2015


____________________________________________________

I think there is a witch haunting my dev system. :-)

System: i686, GCC-4.9.2, libtool-2.4.2
____________________________________________________

Igor, sorry for writing this just after the commit you did and for the
long introduction that I know you hate.     :-)

I try to keep my dev system up to date with BLFS, exception for some of
the packages I never update, some that conflicts with what I use, or
some of those I never use (Bruce knows that), although updating also
some of the first and last categories.

I don't like to be the "bearer of bad news". Therefore its is a
coincidence, not nitpicking or other negative interpretation.

I was much surprised this morning, when, before starting work on the
tickets,  MesaLib-10.4.3 make failed. After the problem yesterday with
stunnel, I started thinking my system had somehow broken.

_TECHNICAL STUFF_:

make error (edited the PATH, to decrease line length):

{{{
Making all in .
make[4]: Entering directory '/tmp/Mesa-10.4.3/src/util'
  CC       libmesautil_la-hash_table.lo
libtool: Version mismatch error.  This is libtool 2.4.4, but the
libtool: definition of this LT_INIT comes from libtool 2.4.2.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.4
libtool: and run autoconf again.
Makefile:634: recipe for target 'libmesautil_la-hash_table.lo' failed
make[4]: *** [libmesautil_la-hash_table.lo] Error 63
make[4]: Leaving directory '/tmp/Mesa-10.4.3/src/util'
Makefile:709: recipe for target 'all-recursive' failed
}}}

I can't do what is recommended ("You should recreate aclocal.m4 with
macros from libtool 2.4.4 and run autoconf again", as written above,
installed is libtool-2.4.2.

Problem is that the "libtool" script in the root of the source code:

{{{
$ grep 2.4 Mesa-10.4.3/libtool.orig
macro_version=2.4.2
# libtool (GNU libtool) 2.4.4
VERSION=2.4.4
package_revision=2.4.4
    printf 0123456789 >conftest.in
    printf 0123456789 >conftest.in
scriptversion='(GNU libtool) 2.4.4'
       version:        $progname (GNU libtool) 2.4.4
}}}

You can see both "libtool" versions, 2.4.2 and 2.4.4, there.

I thought about two solutions: either remove Mesa-10.4.3/libtool or try
to create a new one, and decided to try the latter, although I found a
recommendation for not editing it:

{{{
# ### END LIBTOOL CONFIG

#! /bin/sh
## DO NOT EDIT - This file generated from ./build-aux/ltmain.in
##               by inline-source v2014-01-03.01

# libtool (GNU libtool) 2.4.4
}}}

"Mesa-10.4.3/libtool" appears to be created by "autogen.sh". Running
again, we have a warning recommending to to use "--force" with
"autoreconf", and I learned that it is run by "autogen.sh".

Solution:
sed -i 's/autoreconf/& -f/' ./autogen.sh

Now "libtool" seems more reasonable:

{{{
$ grep 2.4 Mesa-10.4.3/libtoolmacro_version=2.4.2
# libtool (GNU libtool) 2.4.2
#         $progname:	(GNU libtool) 2.4.2
VERSION=2.4.2
}}}

With this modified libtool, MesaLib-10.4.3 is now installed and running
fine.

_DISCUSSION_

Of course there are alternatives, such as running autoreconf and the
configure, instead of autogen.sh (didn't try).

Whatever, it seems the page needs a modification. If you decide in
favour of the sed, a Note such as the one in 'stunnel" is necessary. If
running "autoreconf -v -f -i" (equivalent to the sed above) and then
configure, probably no note would be necessary, but you might not want
this, because it could mean more work for you.

If you agree with the modifications but doesn't want to do the commit
yourself, I volunteer.

While waiting for your (or anybody else's) reply, I will try the
"autoreconf/configure" combination (thought about it when writing this
post).

Thanks.

-- 
[]s,
Fernando


More information about the blfs-dev mailing list