Bug 61361 - Version mismatch error. This is libtool 2.4.2, but the definition of this LT_INIT comes from libtool 2.2.8.
Summary: Version mismatch error. This is libtool 2.4.2, but the definition of this LT...
Status: RESOLVED INVALID
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium blocker
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-23 17:29 UTC by NOT ACTIVE SINCE DECADES, PLEASE DELETE ME
Modified: 2014-09-22 17:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description NOT ACTIVE SINCE DECADES, PLEASE DELETE ME 2013-02-23 17:29:02 UTC 
This happens since 9.0.1

make[3]: Entering directory `(...)/Mesa-9.1/src/mapi/shared-glapi'
  CC     entry.lo
libtool: Version mismatch error.  This is libtool 2.4.2, but the
libtool: definition of this LT_INIT comes from libtool 2.2.8.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2
libtool: and run autoconf again.
make[3]: *** [entry.lo] error 63
Comment 1 Andreas Boll 2013-02-27 10:03:30 UTC 
Does this happen if you build from git or from release tarball?
Comment 2 NOT ACTIVE SINCE DECADES, PLEASE DELETE ME 2013-02-27 23:20:17 UTC 
release tarball
Comment 3 Andreas Boll 2013-02-28 20:32:55 UTC 
Could you try to build from git?
Comment 4 NOT ACTIVE SINCE DECADES, PLEASE DELETE ME 2013-03-01 04:23:26 UTC 
works, but can't run the checks because I have an r200 with no shaders! is the check configurable?
Comment 5 Matt Turner 2013-03-01 05:02:42 UTC 
(In reply to comment #4)
> works, but can't run the checks because I have an r200 with no shaders! is
> the check configurable?

huh?
Comment 6 NOT ACTIVE SINCE DECADES, PLEASE DELETE ME 2013-03-02 05:01:30 UTC 
the check fails at glsl. as far as i understand, the missing support for shaders is the reason. possibly i'm wrong.
Comment 7 Matt Turner 2013-03-02 08:05:46 UTC 
(In reply to comment #6)
> the check fails at glsl. as far as i understand, the missing support for
> shaders is the reason. possibly i'm wrong.

Yeah, I don't think that makes any sense. Post a log.
Comment 8 NOT ACTIVE SINCE DECADES, PLEASE DELETE ME 2013-03-02 15:45:32 UTC 
found the log:

src/glsl/test-suite.log

=========================================
   Mesa 9.2.0: src/glsl/test-suite.log
=========================================

# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: glcpp/tests/glcpp-test
============================

====== Testing for correctness ======
Testing ./glcpp/tests/000-content-with-spaces.c..../glcpp/tests/glcpp-test: 64: arith: syntax error: "total+1"
Comment 9 Matt Turner 2014-09-21 19:54:30 UTC 
Still no idea what's going on here. Need more info.
Comment 10 Emil Velikov 2014-09-22 17:03:08 UTC 
The glsl tests (and nearly all tests in that matter) are checking the integrity of the actual build, rather than the present functionality of the system/driver.

(In reply to comment #6)
> the check fails at glsl. as far as i understand, the missing support for
> shaders is the reason. possibly i'm wrong.
With that said, the above statement does not really make sense.

The version missmatch happens as the binary tarball was distributed with with an older version of libtool than the one you have installed on your system.
It's unfortunate but normal and to resolve it one needs to run the following:
  
 $ autoreconf -vfi

Feel free to reopen if you're seeing the problem with latest mesa (10.2.8 or later) and the command does not help.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.