If I want to build Mesa 10.1 branch with DRI3 enabled (the default), it fails. I have to use --disable-dri3 to be able to build Mesa. I have the following package versions installed, are they too old? ii libxcb-dri3-0:amd64 1.10-2 amd64 X C Binding, dri3 extension ii libxcb-dri3-dev:amd64 1.10-2 amd64 X C Binding, dri3 extension, development files ii x11proto-dri3-dev 1.0-1 all X11 DRI3 extension wire protocol $ ./configure --enable-dri --enable-glx-tls --enable-shared-glapi --enable-texture-float --enable-xa --disable-xvmc --disable-vdpau --with-gallium-drivers=r600,swrast LLVM_CONFIG=/usr/bin/llvm-config-3.4 --enable-debug [... this succeeds] prefix: /usr/local exec_prefix: ${prefix} libdir: ${exec_prefix}/lib includedir: ${prefix}/include OpenGL: yes (ES1: no ES2: no) OpenVG: no OSMesa: no DRI drivers: i915 i965 nouveau r200 radeon swrast DRI driver dir: ${libdir}/dri GLX: DRI-based EGL: yes EGL platforms: x11 EGL drivers: builtin:egl_glx builtin:egl_dri2 llvm: yes llvm-config: /usr/bin/llvm-config-3.4 llvm-version: 3.4 Gallium: yes Target dirs: dri-swrast r600/dri Winsys dirs: radeon/drm sw sw/dri Driver dirs: galahad identity llvmpipe noop r600 rbug softpipe trace Trackers dirs: dri xa 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 -g -O0 CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -g -O0 Macros: -D_GNU_SOURCE -DHAVE_PTHREAD -DDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DHAVE_LIBUDEV -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS -DHAVE_DRI3 -DHAVE_MINCORE -DHAVE_LLVM=0x0304 LLVM_CFLAGS: -I/usr/lib/llvm-3.4/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS LLVM_CXXFLAGS: -I/usr/lib/llvm-3.4/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fvisibility-inlines-hidden -fno-exceptions -fPIC -Woverloaded-virtual -Wcast-qual LLVM_CPPFLAGS: -I/usr/lib/llvm-3.4/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS PYTHON2: python2 Run 'make' to build Mesa $ make [...] make[3]: Entering directory `/home/edwin/HDD/me/language/C++/mesa/src/glx' CC dri3_glx.lo In file included from dri3_glx.c:66:0: /usr/include/xcb/present.h:18:19: fatal error: randr.h: No such file or directory #include "randr.h" ^ compilation terminated. make[3]: *** [dri3_glx.lo] Error 1 FWIW randr.h is in /usr/include/X11/extensions/randr.h. If I add a CPPFLAGS=-I/usr/include/X11/extensions I get a different error: make[3]: Entering directory `/home/edwin/HDD/me/language/C++/mesa/src/glx' CC dri3_glx.lo In file included from dri3_glx.c:66:0: /usr/include/xcb/present.h:139:5: error: unknown type name 'xcb_randr_crtc_t' xcb_randr_crtc_t target_crtc; /**< */ ^ /usr/include/xcb/present.h:336:5: error: unknown type name 'xcb_randr_crtc_t' xcb_randr_crtc_t target_crtc; /**< */
You need the xcb randr.h, not the Xlib randr.h. That should be in a libxcb-randr development package. On debian, that's libxcb-randr0-dev.
The configure should really check for xcb-randr, too then.
(In reply to comment #2) > The configure should really check for xcb-randr, too then. (In reply to comment #1) > You need the xcb randr.h, not the Xlib randr.h. That should be in a > libxcb-randr development package. On debian, that's libxcb-randr0-dev. Indeed, installing that package allowed me to build with DRI3, a configure check would be nice.
(In reply to comment #1) > You need the xcb randr.h, not the Xlib randr.h. That should be in a > libxcb-randr development package. On debian, that's libxcb-randr0-dev. This dependency should be reflected in xcb-present.pc.
There are more dependencies than just "present needs randr" that are missing. The following hack greps each XML extension description for <import> tags and checks if the corresponding .pc.in file contains the correct dependency (And yes, the code generator turns <import> into an include in the public header so these dependencies do exist): $ for xml in ../proto/src/*xml ; do ext=$(basename --suffix=.xml $xml) ; grep '<import' $xml | sed -e 's/<[^>]*>\|[\t ]*//g' | grep -v xproto | while read dep ; do grep -q "xcb-$dep" xcb-$ext.pc.in || echo " $ext depends on $dep, but xcb-$ext.pc.in doesn't list this!" ; done ; done present depends on randr, but xcb-present.pc.in doesn't list this! present depends on xfixes, but xcb-present.pc.in doesn't list this! present depends on sync, but xcb-present.pc.in doesn't list this! randr depends on render, but xcb-randr.pc.in doesn't list this! xinput depends on xfixes, but xcb-xinput.pc.in doesn't list this! I guess the best way to fix this would be to have the generation of the .pc.in files somehow be wired up to the code generator so that these kind of things are done automatically. Sadly the .pc.in files are needed by ./configure and thus cannot be easily generated from make... Alternatively, "make check" could be extended to do something like the above, but in a less hackish way.
(In reply to comment #5) > There are more dependencies than just "present needs randr" that are missing. > > The following hack greps each XML extension description for <import> tags > and checks if the corresponding .pc.in file contains the correct dependency > (And yes, the code generator turns <import> into an include in the public > header so these dependencies do exist): > > $ for xml in ../proto/src/*xml ; do ext=$(basename --suffix=.xml $xml) ; > grep '<import' $xml | sed -e 's/<[^>]*>\|[\t ]*//g' | grep -v xproto | while > read dep ; do grep -q "xcb-$dep" xcb-$ext.pc.in || echo " $ext depends on > $dep, but xcb-$ext.pc.in doesn't list this!" ; done ; done > present depends on randr, but xcb-present.pc.in doesn't list this! > present depends on xfixes, but xcb-present.pc.in doesn't list this! > present depends on sync, but xcb-present.pc.in doesn't list this! > randr depends on render, but xcb-randr.pc.in doesn't list this! > xinput depends on xfixes, but xcb-xinput.pc.in doesn't list this! > > I guess the best way to fix this would be to have the generation of the > .pc.in files somehow be wired up to the code generator so that these kind of > things are done automatically. Sadly the .pc.in files are needed by > ./configure and thus cannot be easily generated from make... > > Alternatively, "make check" could be extended to do something like the > above, but in a less hackish way. What about having a generate-pkg-config.py.in script, which gets the necessary @paths@ and @variables@ filled in via configure, and then runs to generate .pc files directly?
I've posted a pair of patches to the xcb list which validate the dependencies in the .pc files against the constructed header files and then a second patch which uses that information to add missing dependencies. The validation will happen whenever someone does 'make check', which is part of 'make distcheck', a standard part of the X.org release process, so with these two patches in place, we shouldn't have this particular problem in the future.
(In reply to comment #5) > I guess the best way to fix this would be to have the generation of the > .pc.in files somehow be wired up to the code generator so that these kind of > things are done automatically. Sadly the .pc.in files are needed by > ./configure and thus cannot be easily generated from make... The .pc.in files aren't strictly needed by configure, we'd just been using configure to do the simple substitutions needed in them instead of writing a Makefile rule. If we've got more complex work to do, removing them from configure and moving their generation to something run out of the Makefile instead should be simple.
This reminds me that X randrproto package depends on renderproto but the .pc does not list it. No one got impacted as randrproto does not need renderproto to compile, there are only header files. Pardon my ignorance, but could it be just as simple for the XCB project to edit the xcb-randr.pc.in file to add xcb-render in the Requires? And so on... I am assuming that the dependencies are static and do not depend on generated code. Looks to me that randr will always depend on render. The X proto packages should be fixed anyway for completeness and accuracy. I can help with that.
(In reply to comment #9) > Pardon my ignorance, but could it be just as simple for the XCB project to > edit the xcb-randr.pc.in file to add xcb-render in the Requires? And so > on... I am assuming that the dependencies are static and do not depend on > generated code. Looks to me that randr will always depend on render. > the dependency declaration lives in the xml files which live in xcb-proto. those xml files are not static. having to duplicate those declarations in the .pc files when they could just be inferred from the xml sucks.
commit e2813e1cde893f384fa620ff3c13493beebabe0c Author: Keith Packard <keithp@keithp.com> Date: Wed Feb 12 14:15:46 2014 -0800 Update .pc file Requires lines to express full dependencies Some xcb libraries depend on others; make these dependencies explicit in the .pc files that are installed. This change was generated automatically by running 'check-pc-requires -fix'
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.