Created attachment 58216 [details] Build log from portage libEGL.la fails during linking when a 64bit libglapi.so is available in /usr/lib64 but a 32bit version isn't in /usr/lib32 It's not finding the freshly built copy
Same thing around here. When relinking, it tries to find the libxcb and other 32bit dev libs. However, they can't be installed using packages, at least under Ubuntu 11.10. Here how it ends: CCLD libGL.la *** Warning: Linking the shared library libGL.la against the *** static library ../mapi/glapi/libglapi.a is not portable! /usr/bin/ld.bfd.real: cannot find -lX11-xcb /usr/bin/ld.bfd.real: cannot find -lX11 /usr/bin/ld.bfd.real: cannot find -lxcb-glx /usr/bin/ld.bfd.real: cannot find -lxcb /usr/lib/x86_64-linux-gnu/libdrm.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[2]: *** [libGL.la] Error 1 Would compiling 32bit libX11 and libxcb be a solution?
They are external dependencies, you will need to provide them to build a 32bit mesa and isn't related to this bug
I suspect this is fixed by: http://cgit.freedesktop.org/mesa/mesa/commit/configure.ac?id=ca760181b4420696c7e86aa2951d7203522ad1e8 commit ca760181b4420696c7e86aa2951d7203522ad1e8 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Fri Mar 16 12:55:40 2012 -0400 shared-glapi: Convert to automake This fixes a build problem where EGL links to libgbm.la, which encodes a relative path to it's libglapi.so dependency. The relative path breaks when the linker tries to resolve it from src/egl/main instead of src/gbm. Typically we silently fall back to the system libglapi.so, which is wrong and breaks when there isn't one. Morale of the story: don't mix mklib and libtool.
Yes this seems to have fixed it for me
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.