Bug 80848 - [dri3] Building mesa fails with dri3 enabled
Summary: [dri3] Building mesa fails with dri3 enabled
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: GLX (show other bugs)
Version: git
Hardware: All Linux (All)
: medium blocker
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-03 12:30 UTC by Juha-Pekka Heikkilä
Modified: 2014-12-03 11:20 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
configure: check for core xcb (libxcb.so) and link libGL against it (2.18 KB, patch)
2014-07-11 23:15 UTC, Emil Velikov
Details | Splinter Review
Makefile from src/gxl/ both failing and working makefiles are indentical. (35.43 KB, text/plain)
2014-07-30 11:57 UTC, Juha-Pekka Heikkilä
Details
log of failed dri3 build with Emil's patch included (34.24 KB, text/plain)
2014-11-26 08:40 UTC, Juha-Pekka Heikkilä
Details
requested logs (63.59 KB, application/x-gzip)
2014-12-03 11:20 UTC, Juha-Pekka Heikkilä
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Juha-Pekka Heikkilä 2014-07-03 12:30:28 UTC
I noticed building mesa with dri3 fails on my machine at linking stage. First
failing patch seems to be this one "loader: Use drirc device_id parameter 
in complement to DRI_PRIME" 3ecd9e1a93817180fa5b280e5fe11c903cca38ba

Complaints I get seems to be about xcb, my libxcb is build with default options
and libxcb git tree head is at 125135452a554e89e49448e2c1ee6658324e1095

* Options how I configured mesa:

PKG_CONFIG_PATH=/opt/lib/pkgconfig ./autogen.sh --prefix=/opt --enable-gles2 
--enable-gles1 --enable-shared-glapi --without-gallium-drivers --enable-64-bit 
--with-dri-drivers=i965

* Output from configure:

autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal -I m4
autoreconf2.50: configure.ac: tracing
autoreconf2.50: running: libtoolize --install --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `bin'.
libtoolize: copying file `bin/config.guess'
libtoolize: copying file `bin/config.sub'
libtoolize: copying file `bin/install-sh'
libtoolize: copying file `bin/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
autoreconf2.50: running: /usr/bin/autoconf
autoreconf2.50: configure.ac: not using Autoheader
autoreconf2.50: running: automake --add-missing --copy --no-force
configure.ac:23: installing `bin/ar-lib'
configure.ac:53: installing `bin/compile'
configure.ac:15: installing `bin/missing'
src/egl/drivers/dri2/Makefile.am: installing `bin/depcomp'
autoreconf2.50: Leaving directory `.'
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking dependency style of gcc... gcc3
checking for gmake... no
checking for make... make
checking for python2... python2
checking for a sed that does not truncate output... /bin/sed
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for bison... bison -y
checking if bison is the parser generator... yes
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking if flex is the lexer generator... yes
checking for perl... /usr/bin/perl
checking for indent... cat
checking if compiling with clang... no
checking whether gcc version is sufficient... yes
checking for __builtin_bswap32... yes
checking for __builtin_bswap64... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether gcc supports -Werror=missing-prototypes... yes
checking whether gcc supports -fvisibility=hidden... yes
checking whether g++ supports -fvisibility=hidden... yes
checking whether C compiler accepts -msse4.1... yes
checking if ld supports -Bsymbolic... yes
checking whether ld supports --gc-sections... yes
checking if the linker supports version-scripts... yes
checking whether to enable assembly... yes, x86_64
checking for dlopen... no
checking for dlopen in -ldl... yes
checking for dladdr... no
checking for clock_gettime... yes
checking for posix_memalign... yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... no
checking for LIBDRM... yes
checking for LIBUDEV... yes
checking for GLPROTO... yes
checking for DRI2PROTO... yes
checking for DRI3PROTO... yes
checking for PRESENTPROTO... yes
checking for XF86VIDMODE... yes
checking for DRIGL... yes
checking for EXPAT... yes
checking for INTEL... yes
checking for mincore... yes
checking for XCB_DRI2... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating src/egl/drivers/dri2/Makefile
config.status: creating src/egl/main/Makefile
config.status: creating src/egl/main/egl.pc
config.status: creating src/egl/wayland/Makefile
config.status: creating src/egl/wayland/wayland-drm/Makefile
config.status: creating src/egl/wayland/wayland-egl/Makefile
config.status: creating src/egl/wayland/wayland-egl/wayland-egl.pc
config.status: creating src/gallium/auxiliary/Makefile
config.status: creating src/gallium/auxiliary/pipe-loader/Makefile
config.status: creating src/gallium/drivers/Makefile
config.status: creating src/gallium/drivers/freedreno/Makefile
config.status: creating src/gallium/drivers/galahad/Makefile
config.status: creating src/gallium/drivers/i915/Makefile
config.status: creating src/gallium/drivers/identity/Makefile
config.status: creating src/gallium/drivers/ilo/Makefile
config.status: creating src/gallium/drivers/llvmpipe/Makefile
config.status: creating src/gallium/drivers/noop/Makefile
config.status: creating src/gallium/drivers/nouveau/Makefile
config.status: creating src/gallium/drivers/r300/Makefile
config.status: creating src/gallium/drivers/r600/Makefile
config.status: creating src/gallium/drivers/radeon/Makefile
config.status: creating src/gallium/drivers/radeonsi/Makefile
config.status: creating src/gallium/drivers/rbug/Makefile
config.status: creating src/gallium/drivers/softpipe/Makefile
config.status: creating src/gallium/drivers/svga/Makefile
config.status: creating src/gallium/drivers/trace/Makefile
config.status: creating src/gallium/state_trackers/Makefile
config.status: creating src/gallium/state_trackers/clover/Makefile
config.status: creating src/gallium/state_trackers/dri/Makefile
config.status: creating src/gallium/state_trackers/dri/drm/Makefile
config.status: creating src/gallium/state_trackers/dri/sw/Makefile
config.status: creating src/gallium/state_trackers/egl/Makefile
config.status: creating src/gallium/state_trackers/gbm/Makefile
config.status: creating src/gallium/state_trackers/glx/xlib/Makefile
config.status: creating src/gallium/state_trackers/omx/Makefile
config.status: creating src/gallium/state_trackers/osmesa/Makefile
config.status: creating src/gallium/state_trackers/vdpau/Makefile
config.status: creating src/gallium/state_trackers/vega/Makefile
config.status: creating src/gallium/state_trackers/xa/Makefile
config.status: creating src/gallium/state_trackers/xvmc/Makefile
config.status: creating src/gallium/targets/Makefile
config.status: creating src/gallium/targets/dri-swrast/Makefile
config.status: creating src/gallium/targets/dri/Makefile
config.status: creating src/gallium/targets/egl-static/Makefile
config.status: creating src/gallium/targets/gbm/Makefile
config.status: creating src/gallium/targets/libgl-xlib/Makefile
config.status: creating src/gallium/targets/omx/Makefile
config.status: creating src/gallium/targets/opencl/Makefile
config.status: creating src/gallium/targets/osmesa/Makefile
config.status: creating src/gallium/targets/osmesa/osmesa.pc
config.status: creating src/gallium/targets/pipe-loader/Makefile
config.status: creating src/gallium/targets/vdpau/Makefile
config.status: creating src/gallium/targets/xa/Makefile
config.status: creating src/gallium/targets/xa/xatracker.pc
config.status: creating src/gallium/targets/xvmc/Makefile
config.status: creating src/gallium/tests/trivial/Makefile
config.status: creating src/gallium/tests/unit/Makefile
config.status: creating src/gallium/winsys/Makefile
config.status: creating src/gallium/winsys/freedreno/drm/Makefile
config.status: creating src/gallium/winsys/i915/drm/Makefile
config.status: creating src/gallium/winsys/intel/drm/Makefile
config.status: creating src/gallium/winsys/nouveau/drm/Makefile
config.status: creating src/gallium/winsys/radeon/drm/Makefile
config.status: creating src/gallium/winsys/svga/drm/Makefile
config.status: creating src/gallium/winsys/sw/dri/Makefile
config.status: creating src/gallium/winsys/sw/fbdev/Makefile
config.status: creating src/gallium/winsys/sw/null/Makefile
config.status: creating src/gallium/winsys/sw/wayland/Makefile
config.status: creating src/gallium/winsys/sw/wrapper/Makefile
config.status: creating src/gallium/winsys/sw/xlib/Makefile
config.status: creating src/gbm/Makefile
config.status: creating src/gbm/main/gbm.pc
config.status: creating src/glsl/Makefile
config.status: creating src/glx/Makefile
config.status: creating src/glx/apple/Makefile
config.status: creating src/glx/tests/Makefile
config.status: creating src/gtest/Makefile
config.status: creating src/loader/Makefile
config.status: creating src/mapi/Makefile
config.status: creating src/mapi/es1api/Makefile
config.status: creating src/mapi/es1api/glesv1_cm.pc
config.status: creating src/mapi/es2api/Makefile
config.status: creating src/mapi/es2api/glesv2.pc
config.status: creating src/mapi/glapi/Makefile
config.status: creating src/mapi/glapi/gen/Makefile
config.status: creating src/mapi/glapi/tests/Makefile
config.status: creating src/mapi/shared-glapi/Makefile
config.status: creating src/mapi/shared-glapi/tests/Makefile
config.status: creating src/mapi/vgapi/Makefile
config.status: creating src/mapi/vgapi/vg.pc
config.status: creating src/mesa/Makefile
config.status: creating src/mesa/gl.pc
config.status: creating src/mesa/drivers/dri/dri.pc
config.status: creating src/mesa/drivers/dri/common/Makefile
config.status: creating src/mesa/drivers/dri/common/xmlpool/Makefile
config.status: creating src/mesa/drivers/dri/i915/Makefile
config.status: creating src/mesa/drivers/dri/i965/Makefile
config.status: creating src/mesa/drivers/dri/Makefile
config.status: creating src/mesa/drivers/dri/nouveau/Makefile
config.status: creating src/mesa/drivers/dri/r200/Makefile
config.status: creating src/mesa/drivers/dri/radeon/Makefile
config.status: creating src/mesa/drivers/dri/swrast/Makefile
config.status: creating src/mesa/drivers/osmesa/Makefile
config.status: creating src/mesa/drivers/osmesa/osmesa.pc
config.status: creating src/mesa/drivers/x11/Makefile
config.status: creating src/mesa/main/tests/Makefile
config.status: creating src/mesa/main/tests/hash_table/Makefile
config.status: executing depfiles commands
config.status: executing libtool commands

        prefix:          /opt
        exec_prefix:     ${prefix}
        libdir:          ${exec_prefix}/lib
        includedir:      ${prefix}/include

        OpenGL:          yes (ES1: yes ES2: yes)
        OpenVG:          no

        OSMesa:          no

        DRI platform:    drm
        DRI drivers:     i965 
        DRI driver dir:  ${libdir}/dri
        GLX:             DRI-based

        EGL:             yes
        EGL platforms:   x11
        EGL drivers:     builtin:egl_dri2

        llvm:            no

        Gallium:         no

        Shared libs:     yes
        Static libs:     no
        Shared-glapi:    yes

        CFLAGS:          -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -m64
        CXXFLAGS:        -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -m64
        Macros:          -DUSE_EXTERNAL_DXTN_LIB=1 -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DHAVE_LIBUDEV -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DHAVE_DRI3 -DHAVE_MINCORE

        PYTHON2:         python2

        Run 'make' to build Mesa



* Errors I get at "make install":

 /bin/bash ../../libtool   --mode=install /usr/bin/install -c   libGL.la '/opt/lib'
libtool: install: warning: relinking `libGL.la'
libtool: install: (cd /home/jheikkil/workspace/mesamesa/mesa2/mesa/src/glx; /bin/bash /home/jheikkil/workspace/mesamesa/mesa2/mesa/libtool  --silent --tag CC --mode=relink gcc -I../../include -I../../include/GL/internal -I../../src/loader -I../../src/mapi -I../../src/mapi/glapi -I../../src/mapi -I../../src/mapi/glapi -fvisibility=hidden -DGLX_SHARED_GLAPI -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\"/opt/lib/dri\" -DUSE_EXTERNAL_DXTN_LIB=1 -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DHAVE_LIBUDEV -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DHAVE_DRI3 -DHAVE_MINCORE -I/opt/include -I/opt/include/libdrm -I/opt/include -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -m64 -no-undefined -version-number 1:2 -Wl,-Bsymbolic -Wl,--gc-sections -Wl,--no-undefined -o libGL.la -rpath /opt/lib libglx.la ../../src/mapi/glapi/libglapi.la ../../src/mapi/shared-glapi/libglapi.la -L/opt/lib -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb-dri2 -lxcb-dri3 -lxcb-present -lxcb-randr -lxcb-xfixes -lxcb-render -lxcb-shape -lxcb-sync -lxcb -lxshmfence -lXxf86vm -L/opt/lib -ldrm -lm -lpthread -ldl )
./.libs/libglx.a(dri3_glx.o): In function `dri3_flush_present_events':
/home/jheikkil/workspace/mesamesa/mesa2/mesa/src/glx/dri3_glx.c:953: undefined reference to `xcb_poll_for_special_event'
./.libs/libglx.a(dri3_glx.o): In function `dri3_find_back':
/home/jheikkil/workspace/mesamesa/mesa2/mesa/src/glx/dri3_glx.c:1191: undefined reference to `xcb_wait_for_special_event'
./.libs/libglx.a(dri3_glx.o): In function `dri3_wait_for_event':
/home/jheikkil/workspace/mesamesa/mesa2/mesa/src/glx/dri3_glx.c:433: undefined reference to `xcb_wait_for_special_event'
./.libs/libglx.a(dri3_glx.o): In function `dri3_destroy_drawable':
/home/jheikkil/workspace/mesamesa/mesa2/mesa/src/glx/dri3_glx.c:296: undefined reference to `xcb_unregister_for_special_event'
./.libs/libglx.a(dri3_glx.o): In function `dri3_update_drawable':
/home/jheikkil/workspace/mesamesa/mesa2/mesa/src/glx/dri3_glx.c:1000: undefined reference to `xcb_register_for_special_xge'
/home/jheikkil/workspace/mesamesa/mesa2/mesa/src/glx/dri3_glx.c:1032: undefined reference to `xcb_unregister_for_special_event'
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libGL.la' with the above command before installing it
Comment 1 Bryan Cain 2014-07-09 17:51:56 UTC
I'm getting the same errors at make install even without compiling i965, with this as my autogen string:

./autogen.sh --enable-texture-float --with-dri-drivers= --disable-gallium-llvm --with-gallium-drivers=nouveau --prefix=/home/bryan/wayland --enable-debug --with-egl-platforms=x11,wayland,drm --enable-gbm

This is just a guess, but maybe it's a problem with non-standard build prefixes?  The XCB libraries in $PREFIX/lib are compiled from the latest git, but the version installed in /usr/lib on my machine is ancient.
Comment 2 Emil Velikov 2014-07-09 20:03:09 UTC
All of the missing symbols are coming from libxcb commit 7983bf0fbdc(Add support for receiving fds in replies). Commit is part of libxcb-1.9.2 and libxcb-1.10.

Bryan,
Seems like you're missing the PKG_CONFIG_PATH which leads to the lack to the $PREFIX/include (or similar) -I flags thus the build break.

Juha-Pekka Heikkilä,
Have you build libxcb 1.9.2 or newer in the customer prefix ? If so we'll just need a oneline fix following Keith's confirmation of the following.

Keith

Can you clarify if we need to link against libxcb.so _only_ when building with dri3 or if this requirement has been there for ages ? Current mesa does not check for the package thus it picks up the system include/libs.

This may be the key for the issues you and/or others have noticed (steamos-mesa has all the dri3 patches reverted).

Cheers
Emil
Comment 3 Bryan Cain 2014-07-09 20:14:22 UTC
I can make sure once I get home, but I'm fairly sure that my PKG_CONFIG_PATH is set properly.  If it isn't, then it should fail during compilation or linking, but those both succeed.  As it is, the errors don't show up until 'make install' is run and libtool tries to relink libGL.
Comment 4 Keith Packard 2014-07-10 00:52:32 UTC
(In reply to comment #2)

> Can you clarify if we need to link against libxcb.so _only_ when building
> with dri3 or if this requirement has been there for ages ? Current mesa does
> not check for the package thus it picks up the system include/libs.

DRI2 also uses xcb, and the configure.ac script does look for the xcb-dri3 package, along with piles of other xcb packages when building either DRI2 or DRI3
Comment 5 Emil Velikov 2014-07-10 02:13:30 UTC
(In reply to comment #4)
> (In reply to comment #2)
> 
> > Can you clarify if we need to link against libxcb.so _only_ when building
> > with dri3 or if this requirement has been there for ages ? Current mesa does
> > not check for the package thus it picks up the system include/libs.
> 
> DRI2 also uses xcb, and the configure.ac script does look for the xcb-dri3
> package, along with piles of other xcb packages when building either DRI2 or
> DRI3

Indeed. Yet I'm talking about a slightly different thing here.

The failing functions rely on core xcb (for lack of better wording of) rather than xcb-*. Obviously we're checking and using xcb-* but now (or since some time) we explicitly depend on libxcb.so.
Comment 6 Emil Velikov 2014-07-11 21:46:19 UTC
So after a bit of tinkering with objdump, libxcb.so, libGL.so and mesa's sources the following files use core xcb functions:

src/glx/create_context.c
src/glx/tests/create_context_unittest.cpp
src/glx/dri3_glx.c
src/egl/drivers/dri2/platform_x11.c
src/gallium/auxiliary/vl/vl_winsys_dri.c

So we should be checking/linking against xcb in:

libGL (unconditionally)
libEGL (when building the x11 backend)
libvdpau* (unconditionally)

I'll prep a few patches that correctly link the libraries against libxcb.
Comment 7 Emil Velikov 2014-07-11 23:15:13 UTC
Created attachment 102646 [details] [review]
configure: check for core xcb (libxcb.so) and link libGL against it

This patch should resolve the problem. Can you give it a try ?
Comment 8 Emil Velikov 2014-07-17 17:11:13 UTC
Juha-Pekka, Bryan

Can you guys test the patch in comment 7 ? I feel slightly reluctant about breaking my system in order to test it myself.
Comment 9 Bryan Cain 2014-07-23 16:25:04 UTC
That patch makes no difference for me.
Comment 10 Emil Velikov 2014-07-23 19:00:58 UTC
(In reply to comment #9)
> That patch makes no difference for me.

Hmm in that case I would suspect that you're hit by a more elaborate (and different) bug than the one reported by Juha-Pekka. If the original link succeeds and we fail at the re-linking stage, that indicates that the LDFLAGS|LIBS are somewhat bonkers. Which one(s) I'm not sure :\

There was a mildly related issue here [1]. You're building without llvm so I'm not sure it will help, still worth a shot though. *Apply on top of the patch in comment 7.

Cheers,
Emil
[1] https://bugs.gentoo.org/show_bug.cgi?id=501328#c47

Would be great if Juha-Pekka can confirm if the my patch helps in his case or not.
Comment 11 Juha-Pekka Heikkilä 2014-07-28 09:54:18 UTC
Hi, sorry I've been away from internet for a while. I just tried your patch on top of commit be8bc588b93286dff6a6c1e8594ec40da50658ff "glsl/cs: Add several GLSL compute shader variables" but it did not seem to make a difference. Before applying the patch I did git clean -dfx to avoid any intereference but the errors seem to stay as is.
Comment 12 Juha-Pekka Heikkilä 2014-07-28 12:16:15 UTC
I did look bit more into this. I notice at linking stage there is no /opt/lib in LIBRARY_PATH nor in "sys_lib_search_path_spec" inside libtool. So PKG_CONFIG_PATH allowed to find correct headers for compile time but not correct libraries for linking time. :/

I fixed this with "PKG_CONFIG_PATH=/opt/lib/pkgconfig CFLAGS=-L/opt/lib CXXFLAGS=-L/opt/lib" on my autogen line and it seemed to work for me, I can compile with dri3 enabled again.
Comment 13 Emil Velikov 2014-07-28 14:05:09 UTC
(In reply to comment #12)
> I did look bit more into this. I notice at linking stage there is no
> /opt/lib in LIBRARY_PATH nor in "sys_lib_search_path_spec" inside libtool.
> So PKG_CONFIG_PATH allowed to find correct headers for compile time but not
> correct libraries for linking time. :/
> 
Yes normally one should provide PKG_CONFIG_PATH whenever the new .pc files are not available in the default location. Strange part is that configure.ac should bail when building dri3 with xcb older than 1.9.3.

Can you attach the contents of the system xcb.pc ?

> I fixed this with "PKG_CONFIG_PATH=/opt/lib/pkgconfig CFLAGS=-L/opt/lib
> CXXFLAGS=-L/opt/lib" on my autogen line and it seemed to work for me, I can
> compile with dri3 enabled again.

Hmm does the includedir and Libs flag of /opt/lib/pkgconfig/xcb.pc match the location of the header/library for the new xcb ? It seems like there is either a bug in xcb somewhere or you're using some strange method of building and/or installing xcb.
Comment 14 Juha-Pekka Heikkilä 2014-07-29 07:10:06 UTC
I paste the contents here for both xcb.pc files as they're short. Directories/files where they point are valid, I don't see anything wrong in these.

/opt/lib/pkgconfig/xcb.pc:
prefix=/opt
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
xcbproto_version=1.10

Name: XCB
Description: X-protocol C Binding
Version: 1.10
Requires.private: pthread-stubs xau >= 0.99.2 xdmcp
Libs: -L${libdir} -lxcb
Libs.private: 
Cflags: -I${includedir}

[EOF]

/usr/local/lib/pkgconfig/xcb.pc:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
xcbproto_version=1.9

Name: XCB
Description: X-protocol C Binding
Version: 1.9
Requires.private: pthread-stubs xau >= 0.99.2 xdmcp
Libs: -L${libdir} -lxcb
Libs.private: 
Cflags: -I${includedir}

[EOF]

Here I see changed just prefix, xcbproto_version and Version. New libxcb is at its given location:

ls /opt/lib/libxcb.*
/opt/lib/libxcb.a  /opt/lib/libxcb.la  /opt/lib/libxcb.so  /opt/lib/libxcb.so.1  /opt/lib/libxcb.so.1.1.0

ls /opt/include/xcb/
bigreq.h     dpms.h  glx.h      record.h  screensaver.h  sync.h    xc_misc.h  xfixes.h    xkb.h     xselinux.h  xvmc.h
composite.h  dri2.h  present.h  render.h  shape.h        xcbext.h  xevie.h    xinerama.h  xprint.h  xtest.h
damage.h     dri3.h  randr.h    res.h     shm.h          xcb.h     xf86dri.h  xinput.h    xproto.h  xv.h

These were installed here with
make
sudo make install
Comment 15 Emil Velikov 2014-07-29 16:12:47 UTC
(In reply to comment #14)
> I paste the contents here for both xcb.pc files as they're short.
> Directories/files where they point are valid, I don't see anything wrong in
> these.
> 
AFAICT they look good and you're doing everything correctly, so ... back to square one :\

> /usr/local/lib/pkgconfig/xcb.pc:
Do you have xcb and/or pkgconfig available in /usr/lib (without local) ?

Can you run git clean -nxd before and after building/installing commit 3ecd9e1a938 and attach the resulting src/glx/Makefile(s). It seems rather odd that it causes such behaviour.
Comment 16 Juha-Pekka Heikkilä 2014-07-30 11:57:16 UTC
Created attachment 103683 [details]
Makefile from src/gxl/ both failing and working makefiles are indentical.

Makefiles for 7ab925a6aafca.. (working) and 3ecd9e1a93817.. (failing) were identical thus attach only one makefile.
Comment 17 Juha-Pekka Heikkilä 2014-07-30 13:06:38 UTC
I did continue poking at this one today. I notice if I revert 3ecd9e1a93817180fa5b280e5fe11c903cca38ba I can compile with dri3 but don't yet know why is it so. I did try stracing  the problematic libtool line and see libxcb is accessed only from /opt/lib and objdump says my libxcb does have the symbols which are not found here.

If I revert 3ecd9.. problematic libtool line stays the same as well as libtool seems to stay without changes. I think I have to redo these tests tomorrow because nothing seems to change but still after reverting 3ecd9e1a93817180fa5b280e5fe11c903cca38ba I can build with dri3; Makefile in src/glx stay the same, libtool stay the same and libtool parameters seem to stay the same. Maybe I forgot to do git clean as some pass.

Anyhow, 3ecd9e1a93817180fa5b280e5fe11c903cca38ba seems to be the source of this problem. Can you Bryan test if reverting 3ecd9.. fixes the problem for you too?
Comment 18 Tapani Pälli 2014-08-01 12:06:32 UTC
I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit environment) and my problems went away by reverting

3ecd9e1a93817180fa5b280e5fe11c903cca38ba

For some reason otherwise a wrong version (64bit one) of libexpat got included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that is why I tried the revert. I'll try to see why this happens.
Comment 19 Tapani Pälli 2014-08-01 12:13:01 UTC
(In reply to comment #18)
> I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit
> environment) and my problems went away by reverting
> 
> 3ecd9e1a93817180fa5b280e5fe11c903cca38ba
> 
> For some reason otherwise a wrong version (64bit one) of libexpat got
> included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that
> is why I tried the revert. I'll try to see why this happens.

whoopsie forgot to paste my build command line:

INTEL_CFLAGS='-I/opt/include -I/opt/include/libdrm' INTEL_LIBS='-L/opt/lib -ldrm_intel' CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/opt --enable-gles2 --without-gallium-drivers --enable-32-bit --with-dri-drivers=i965 --with-egl-platforms=x11 --disable-osmesa --disable-vdpau --disable-dri3 --enable-debug --enable-glx-tls --enable-texture-float
Comment 20 Emil Velikov 2014-08-01 14:50:58 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit
> > environment) and my problems went away by reverting
> > 
> > 3ecd9e1a93817180fa5b280e5fe11c903cca38ba
> > 
> > For some reason otherwise a wrong version (64bit one) of libexpat got
> > included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that
> > is why I tried the revert. I'll try to see why this happens.
> 
> whoopsie forgot to paste my build command line:
> 
> INTEL_CFLAGS='-I/opt/include -I/opt/include/libdrm' INTEL_LIBS='-L/opt/lib
> -ldrm_intel' CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/opt
> --enable-gles2 --without-gallium-drivers --enable-32-bit
> --with-dri-drivers=i965 --with-egl-platforms=x11 --disable-osmesa
> --disable-vdpau --disable-dri3 --enable-debug --enable-glx-tls
> --enable-texture-float

I find something a bit disturbing here - why would you set INTEL_{CFLAGS,LIBS} rather than relying on pkg-config ?

Your native arch is x86-64 thus the lack of PKG_CONFIG_PATH is the one causing you problems - pkgconfig looks for the variable (none set) then goes into the default dir which has a .pc file pointing to a 64bit library.

Or to put things in a different light - please can we avoid shooting mesa in the back by providing any other flags but PKG_CONFIG_PATH, CFLAGS and CXXFLAGS. Thank you

P.S. Things should just work even without C{XX,}FLAGS='-m32' unless we have a bug somewhere :)
Comment 21 Tapani Pälli 2014-08-02 05:52:09 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit
> > > environment) and my problems went away by reverting
> > > 
> > > 3ecd9e1a93817180fa5b280e5fe11c903cca38ba
> > > 
> > > For some reason otherwise a wrong version (64bit one) of libexpat got
> > > included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that
> > > is why I tried the revert. I'll try to see why this happens.
> > 
> > whoopsie forgot to paste my build command line:
> > 
> > INTEL_CFLAGS='-I/opt/include -I/opt/include/libdrm' INTEL_LIBS='-L/opt/lib
> > -ldrm_intel' CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/opt
> > --enable-gles2 --without-gallium-drivers --enable-32-bit
> > --with-dri-drivers=i965 --with-egl-platforms=x11 --disable-osmesa
> > --disable-vdpau --disable-dri3 --enable-debug --enable-glx-tls
> > --enable-texture-float
> 
> I find something a bit disturbing here - why would you set
> INTEL_{CFLAGS,LIBS} rather than relying on pkg-config ?

because libdrm is the only library I use from under /opt, rest comes from the system

> Your native arch is x86-64 thus the lack of PKG_CONFIG_PATH is the one
> causing you problems - pkgconfig looks for the variable (none set) then goes
> into the default dir which has a .pc file pointing to a 64bit library.

well, it has been working so far without problems though (and this command line actually still works fine on my fedora machine, but on ubuntu it does not), libtool takes care of pointing to the correct arch directory

> Or to put things in a different light - please can we avoid shooting mesa in
> the back by providing any other flags but PKG_CONFIG_PATH, CFLAGS and
> CXXFLAGS. Thank you
> 
> P.S. Things should just work even without C{XX,}FLAGS='-m32' unless we have
> a bug somewhere :)

Unfortunately we do, giving '-m32' manually is the only way to get working 32bit build because we initialize libtool too early (LT_INIT), here's the bug:

https://bugs.freedesktop.org/show_bug.cgi?id=50754
Comment 22 Emil Velikov 2014-08-03 14:41:25 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > (In reply to comment #18)
> > > > I had cross-compilation problems on Ubuntu (building 32bit Mesa on 64bit
> > > > environment) and my problems went away by reverting
> > > > 
> > > > 3ecd9e1a93817180fa5b280e5fe11c903cca38ba
> > > > 
> > > > For some reason otherwise a wrong version (64bit one) of libexpat got
> > > > included to linking. Patch adds $(EXPAT_LIBS) when linking libloader so that
> > > > is why I tried the revert. I'll try to see why this happens.
> > > 
> > > whoopsie forgot to paste my build command line:
> > > 
> > > INTEL_CFLAGS='-I/opt/include -I/opt/include/libdrm' INTEL_LIBS='-L/opt/lib
> > > -ldrm_intel' CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/opt
> > > --enable-gles2 --without-gallium-drivers --enable-32-bit
> > > --with-dri-drivers=i965 --with-egl-platforms=x11 --disable-osmesa
> > > --disable-vdpau --disable-dri3 --enable-debug --enable-glx-tls
> > > --enable-texture-float
> > 
> > I find something a bit disturbing here - why would you set
> > INTEL_{CFLAGS,LIBS} rather than relying on pkg-config ?
> 
> because libdrm is the only library I use from under /opt, rest comes from
> the system
> 
> > Your native arch is x86-64 thus the lack of PKG_CONFIG_PATH is the one
> > causing you problems - pkgconfig looks for the variable (none set) then goes
> > into the default dir which has a .pc file pointing to a 64bit library.
> 
> well, it has been working so far without problems though (and this command
> line actually still works fine on my fedora machine, but on ubuntu it does
> not), libtool takes care of pointing to the correct arch directory
> 
Just because it works (sometimes) it doesn't mean it's a good idea :) Please migrate to using PKG_CONFIG_PATH which should work consistently for every platform. It also scales nicely if more things are available in the custom prefix.

Snippet from the pkg-config man page:
"pkg-config retrieves information about packages from special metadata files. These files are named after the package, and has a .pc extension. On most systems,  pkg-config looks in /usr/lib/pkgconfig, /usr/share/pkgconfig,  /usr/local/lib/pkgconfig and /usr/local/share/pkgconfig for these files. It will additionally look in the colon-separated (on Windows, semicolon-separated) list of directories specified by the PKG_CONFIG_PATH environment variable."

> > Or to put things in a different light - please can we avoid shooting mesa in
> > the back by providing any other flags but PKG_CONFIG_PATH, CFLAGS and
> > CXXFLAGS. Thank you
> > 
> > P.S. Things should just work even without C{XX,}FLAGS='-m32' unless we have
> > a bug somewhere :)
> 
> Unfortunately we do, giving '-m32' manually is the only way to get working
> 32bit build because we initialize libtool too early (LT_INIT), here's the
> bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=50754
Thanks I'll look into it.
Comment 23 Eero Tamminen 2014-08-12 15:44:50 UTC
(In reply to comment #22)
> > https://bugs.freedesktop.org/show_bug.cgi?id=50754
> Thanks I'll look into it.

Thanks, it's pretty embarrasing how long it's been unfixed.
Comment 24 Emil Velikov 2014-09-05 22:31:39 UTC
Gents just pushed a few commits which explicitly checks for xcb and links the relevant libraries against it. This is required as soon (tm) libxcb will remote it's Requires to Requires.private, thus libraries that link against libxcb-* will not implicitly link against core xcb.

Can anyone check the Makefiles and/or strace of the issue for a clean tree? I'm suspecting that autohell may be optimising something leading to the strange experience in comment 16 and 17
Comment 25 Emil Velikov 2014-11-25 00:40:20 UTC
I think I may have cracked this :P

So as we link libGL.so, we use -L (when libs are located in custom location) and -rpath for glapi.

As those two are seen the linker (gcc) seemingly ignores the -L directive and does not add it to the DT_RPATH of the final library. Only the rpath that is explicitly provided ends up in there.

Now the million dollar question is - is this a bug or a feature. If the latter how to we handle things correctly ?
Comment 26 Emil Velikov 2014-11-25 01:12:00 UTC
Scratch-out comment 25. Seems like I've got a bit confused there :)
Comment 27 Emil Velikov 2014-11-25 01:36:10 UTC
Guys if you're still having fun with this can attach the output with the following patch ? It should make ld a bit more chatty on the topic :)

diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index 4515312..5ed7b81 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -130,6 +130,7 @@ GL_LIBS = \
 GL_LDFLAGS = \
        -no-undefined \
        -version-number 1:2 \
+       -Wl,--verbose \
        $(BSYMBOLIC) \
        $(GC_SECTIONS) \
        $(LD_NO_UNDEFINED)
Comment 28 Juha-Pekka Heikkilä 2014-11-26 08:40:47 UTC
Created attachment 110039 [details]
log of failed dri3 build with Emil's patch included

Here is the log with Emil's patch included. Log contain everything "make install" produced. My mesa head was at 60f011af1a370004333cbc3fee7fec137ebd9d6a
Comment 29 Emil Velikov 2014-11-26 17:15:16 UTC
OK so it seems that, on relink, libtool prepends an extra -L or two prior to -L/opt/lib thus gcc/ld might end up finding the system library thus never bothers searching in /opt/lib. The extra -L can be seen when one invokes $ make V=1 ..

It smells like a bug in libtool, despite the response I got on IRC (va at #autotools) that libtool is correct here. Cannot find any hints, neither did he/she mention anything to support that statement :'( The search continues...

Guys can you attach the glx hunk of $ make V=1 && make V=1 install, with the patch in comment 27.
Additionally can you add the last ~15 lines of libtool --help

Thanks
Emil
Comment 30 Juha-Pekka Heikkilä 2014-12-03 11:20:53 UTC
Created attachment 110402 [details]
requested logs

Here are the logs. Sorry for the delay, my build system was confused for a while and needed to fix it.


bug/show.html.tmpl processed on Feb 26, 2017 at 07:41:29.
(provided by the Example extension).