mesa: fa5ed99d8e809fb86e486a40273a4a6971055398 (master) scons: Building targets ... Linking build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5 ... build/linux-x86_64-debug/mesa/libmesa.a(st_manager.os): In function `st_api_make_current': src/mesa/state_tracker/st_manager.c:(.text+0xd4b): undefined reference to `_glapi_check_multithread' build/linux-x86_64-debug/mesa/libmesa.a(context.os): In function `_mesa_make_current': src/mesa/main/context.c:(.text+0x6a3): undefined reference to `_glapi_set_context' src/mesa/main/context.c:(.text+0x6c3): undefined reference to `_glapi_set_dispatch' src/mesa/main/context.c:(.text+0xc05): undefined reference to `_glapi_set_dispatch' build/linux-x86_64-debug/mesa/libmesa.a(dlist.os): In function `_mesa_CallList': src/mesa/main/dlist.c:(.text+0x1b43): undefined reference to `_glapi_set_dispatch' build/linux-x86_64-debug/mesa/libmesa.a(dlist.os): In function `_mesa_NewList': src/mesa/main/dlist.c:(.text+0x2c611): undefined reference to `_glapi_set_dispatch' build/linux-x86_64-debug/mesa/libmesa.a(dlist.os): In function `_mesa_EndList': src/mesa/main/dlist.c:(.text+0x2c84e): undefined reference to `_glapi_set_dispatch' build/linux-x86_64-debug/mesa/libmesa.a(dlist.os):src/mesa/main/dlist.c:(.text+0x2ca66): more undefined references to `_glapi_set_dispatch' follow scons: *** [build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5] Error 1 719000bd7d7d227a721ee24ea49a55ab9a972b56 is the first bad commit commit 719000bd7d7d227a721ee24ea49a55ab9a972b56 Author: José Fonseca <jfonseca@vmware.com> Date: Fri Jul 19 13:08:07 2013 +0100 scons: Disallow undefined symbols in Xlib libGL.so. It's not the first time that, due to missing build dependencies or incomplete commits, we end up with a broken libGL.so that's missing symbols, causing all tests to fail catastrophically. Instead try to catch this sort of issues earlier. :040000 040000 9c51c6ec1425dbd39ddf86111d1c2c36f9491249 37839f87c70f488b26ee1e014b44ac02ac48dc52 M src
This is odd. Vinson, could you wipe the build directory and the source directory ( `git clean -fdx src`) and retry building? Also, how are you building this?
A clean build still repoduces the build error. $ icc --version icc (ICC) 13.1.0 20130121 Copyright (C) 1985-2013 Intel Corporation. All rights reserved. $ icpc --version icpc (ICC) 13.1.0 20130121 Copyright (C) 1985-2013 Intel Corporation. All rights reserved. $ CC=icc CXX=icpc scons [...] Linking build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5 ... build/linux-x86_64-debug/mesa/libmesa.a(st_manager.os): In function `st_api_make_current': src/mesa/state_tracker/st_manager.c:(.text+0xd4b): undefined reference to `_glapi_check_multithread'
Oh, this is with icc? I never tested. I suspect that the build with icc has _always_ has been broken. This commit just brought that problem back to surface (as was the intention). This is easy to check: what does ldd -r build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5 show, when you build it before this commit?
mesa: 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5 (master) $ ldd -r build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5 linux-vdso.so.1 => (0x00007fff9bdff000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f55ca1bf000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f55c9fad000) libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f55c9daa000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f55c9ba4000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f55c999b000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f55c977e000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f55c9576000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f55c9371000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f55c9075000) libimf.so => /opt/intel/composer_xe_2013.2.146/compiler/lib/intel64/libimf.so (0x00007f55c8bb9000) libsvml.so => /opt/intel/composer_xe_2013.2.146/compiler/lib/intel64/libsvml.so (0x00007f55c81ed000) libirng.so => /opt/intel/composer_xe_2013.2.146/compiler/lib/intel64/libirng.so (0x00007f55c7fe6000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f55c7ce6000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f55c7acf000) libintlc.so.5 => /opt/intel/composer_xe_2013.2.146/compiler/lib/intel64/libintlc.so.5 (0x00007f55c7881000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f55c74c2000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f55c72a3000) /lib64/ld-linux-x86-64.so.2 (0x00007f55cbcc9000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f55c70a0000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f55c6e99000) undefined symbol: _glapi_set_dispatch (build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5) undefined symbol: _glapi_check_multithread (build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5) undefined symbol: _glapi_set_context (build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5)
(In reply to comment #4) > mesa: 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5 (master) > > $ ldd -r build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1.5 [..] > undefined symbol: _glapi_set_dispatch ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thanks. Yep, this was failing before. It was merely failing silently (it would fail at runtime.) I don't have direct interest in icc -- AFAIK it's not free for comercial use, and gcc has been good enough. (for llvmpipe the compiler doesn't really matter much, as we JIT the hot spots). If you really care for icc, you'll gonna have to dig into this... You'll probably need to recognize icc, and set env['gcc']=1 on that case.
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.