Bug 79263 - Linking error in egl_gallium.la when compiling 32 bit on multiarch
Summary: Linking error in egl_gallium.la when compiling 32 bit on multiarch
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: EGL (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-26 14:15 UTC by Knut Andre Tidemann
Modified: 2014-05-29 19:02 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Knut Andre Tidemann 2014-05-26 14:15:34 UTC
This morning I was unable to compile a 32 bit mesa from git. 64 bit compiled properly. This was on a 64 bit install of Arch Linux with multiarch enabled and using gcc version 4.9.0 20140521 (prerelease) from the official repositories.


I've bisected the issue to this commit:

7a63bd960c33127dbce0e5802a7cda96dc011104
automake: correctly append the version-script

Here's my configure line for the build:

export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"
export LLVM_CONFIG="/usr/bin/llvm-config32"

CFLAGS="-m32 -msse -msse2 -march=i686 -mfpmath=sse -mtune=generic -O2 -pipe" CXXFLAGS="-m32 -msse -msse2 -march=i686 -mfpmath=sse -mtune=generic -O2 -pipe" ./autogen.sh \
    --prefix=/usr \
    --sysconfdir=/etc \
    --with-dri-driverdir=/usr/lib32/xorg/modules/dri \
    --with-gallium-drivers=r300,r600,nouveau,svga,swrast \
    --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \
    --with-llvm-shared-libs \
    --enable-gallium-egl --enable-shared-glapi \
    --enable-gallium-llvm \
    --enable-gallium-gbm \
    --enable-glx-tls \
    --enable-gles1 \
    --enable-gles2 \
    --enable-egl \
    --enable-dri \
    --enable-glx \
    --disable-xa \
    --enable-osmesa \
    --enable-gbm \
    --enable-texture-float \
    --enable-32-bit  \
    --disable-xvmc \
    --disable-vdpau \
    --libdir=/usr/lib32

The linker error produced is:
make[3]: Entering directory '/var/abs/local/mesa-git/lib32-mesa-git/src/build/src/gallium/targets/egl-static'
  CC       egl.lo
  CC       egl_pipe.lo
  CC       egl_st.lo
  CXXLD    egl_gallium.la
.libs/egl.o: In function `create_drm_screen':
egl.c:(.text+0x8f): undefined reference to `loader_get_driver_for_fd'
.libs/egl.o: In function `_eglMain':
egl.c:(.text+0x1da): undefined reference to `loader_set_logger'
collect2: error: ld returned 1 exit status
Makefile:917: recipe for target 'egl_gallium.la' failed
make[3]: *** [egl_gallium.la] Error 1
make[3]: Leaving directory '/var/abs/local/mesa-git/lib32-mesa-git/src/build/src/gallium/targets/egl-static'
Comment 1 Chia-I Wu 2014-05-28 08:01:41 UTC
The issue was really introduced by

commit 39ae284a6941df5942602c027d4a8863ca35e654
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date:   Sat May 10 15:59:03 2014 +0100

    egl-static: include libradeonwinsys.la only once

which removed libloader.la from LIBADD.  CC Emil.
Comment 2 Emil Velikov 2014-05-28 12:52:12 UTC
Handling of the egl_platform is slightly move convoluted than expected.

platform_drm - things will build nicely as the loader* symbols are provided via gbm/libgbm. Everything else - the symbols are missing.

Might be better off re-adding the libloader + multiple-declarations for now.
Comment 3 Emil Velikov 2014-05-28 22:41:04 UTC
Jose has pushed a patch that adds the symbol back, although it causes a multiple definition of loader* as expected - bug 79382.

Proper fix is available http://patchwork.freedesktop.org/patch/26746/
Comment 4 Emil Velikov 2014-05-29 19:02:55 UTC
Fixed with

commit febec731475a5b288cc50660b2d32780e395b950
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date:   Wed May 28 15:43:35 2014 +0100

    st/egl: do not link against libloader

    Move the link to the final targets, like any other place in
    mesa/gallium. This allows better visibilty and will prevent
    us from including the library archive twice.

    Resolves multiple definition of `loader_get_pci_id_for_fd'

    multiple definition of `loader_get_pci_id_for_fd'


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.