Bug 39515 - FTBFS: libEGL depends on libgbm, but libEGL builds first
Summary: FTBFS: libEGL depends on libgbm, but libEGL builds first
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (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: 2011-07-24 17:37 UTC by Dave Witbrodt
Modified: 2011-07-25 08:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
full build output demonstrating dependency error (862.36 KB, text/plain)
2011-07-24 17:37 UTC, Dave Witbrodt
Details

Description Dave Witbrodt 2011-07-24 17:37:36 UTC
Created attachment 49481 [details]
full build output demonstrating dependency error

I am trying to update my old build system to produce DEB packages for Debian Sid.  The last build from git I tried was May 2 (commit eb0a9e9a).  Much has changed since then, and I found that I needed to update my debian/rules and add some new *.install files, etc.  (Up until that time, my builds worked fine for over a year.)

I had made an archive from git on July 18, but didn't get around to working with it until today.  After making adjustments for the changed 'configure' options and the new 'libgbm' library, among other things, I found that my build failed reproducibly when trying to make libEGL:

    /bin/bash ../../../bin/mklib -o EGL -linker 'gcc' -ldflags '' \
                -major 1 -minor 0 \
                -install ../../../x86_64-linux-gnu  \
                -L../../../x86_64-linux-gnu  -ldl  -lpthread -lX11-xcb -lX11 \
                -lxcb-dri2 -lxcb-xfixes -lxcb-render -lxcb-shape -lxcb \
                -lgbm -ludev -lrt   -ldl -ldrm    -lX11   -ldl \
                eglapi.o eglarray.o eglconfig.o eglcontext.o eglcurrent.o \
                egldisplay.o egldriver.o eglfallbacks.o eglglobals.o \
                eglimage.o egllog.o eglmisc.o eglmode.o eglscreen.o \
                eglstring.o eglsurface.o eglsync.o \
                ../../../src/egl/drivers/dri2/libegl_dri2.a \
                ../../../src/egl/drivers/glx/libegl_glx.a
    mklib: Making Linux shared library:  libEGL.so.1.0
    /usr/bin/ld: cannot find -lgbm
    collect2: ld returned 1 exit status
    mklib: Installing libEGL.so.1.0 libEGL.so.1 libEGL.so in \
                ../../../x86_64-linux-gnu
    mv: cannot stat `libEGL.so.1.0': No such file or directory
    make[4]: Leaving directory `/home/dawitbro/sandbox/xorg-local/mesa/
                mesa-7.12.0+git110724.4d23c6df/src/egl/main'


Later in the build this can be seen:

    /bin/bash ../../../bin/mklib -o gbm -linker 'gcc' -ldflags '' \
                -major 1 -minor 0 \
                -install ../../../x86_64-linux-gnu  \
                -L../../../x86_64-linux-gnu  -ldl -ludev -lrt   \
                gbm.o backend.o common.o  ../../../src/gbm/backends \
                /dri/libgbm_dri.a
    mklib: Making Linux shared library:  libgbm.so.1.0
    mklib: Installing libgbm.so.1.0 libgbm.so.1 libgbm.so in 
                ../../../x86_64-linux-gnu
    make[4]: Leaving directory `/home/dawitbro/sandbox/xorg-local/mesa/
                mesa-7.12.0+git110724.4d23c6df/src/gbm/main'


This looks like a dependency problem, but my skill set is insufficient for trying to solve the problem and submitting a patch.  It could also be a problem with the set of options I have selected; I am only a user, not a developer, so I could easily be the weakest link in the chain here.

Hoping that it is a problem that was addressed since July 18, I did a fresh git pull and tried again.  Same failure.  I am attaching the full output from my attempt to build from the latest version I have:  7.12-devel (July 24) at commit 4d23c6df.  This output (obviously) shows the options used and the commands that were run.
Comment 1 Benjamin Franzke 2011-07-25 00:52:24 UTC
Thanks, should be fixes by 42cdf4074e0f7d561b03a86255fa8f916f906bf6.
Comment 2 Dave Witbrodt 2011-07-25 08:58:30 UTC
Works great!  Built, packaged, and installed perfectly.  Tested with 'glxinfo' first, then a few 3D apps:  all is well.

Thanks for the quick response.


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.