[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:43:06 PST 2015


On 26-01-2015 11:22, Fernando de Oliveira wrote:
> ____________________________________________________
> 
> 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).

This combination produces the same installed files.

> Thanks.
> 


-- 
[]s,
Fernando


More information about the blfs-dev mailing list