eselect opengl links GL headers from inconsistent sources into /usr/include/GL, causing #include <GL/glx.h> to fail with media-libs/mesa-10.0.0_rc1: $ ls -l /usr/include/GL/glx{,ext}.h # note "xorg-x11" vs. "global" lrwxrwxrwx 1 root root 44 Nov 19 17:27 /usr/include/GL/glx.h -> ../../lib64/opengl/xorg-x11/include/GL/glx.h lrwxrwxrwx 1 root root 45 Nov 19 17:27 /usr/include/GL/glxext.h -> ../../lib64/opengl/global/include/GL/glxext.h $ ls -l /usr/lib64/opengl/xorg-x11/include/GL/glx.h /usr/lib64/opengl/global/include/GL/glxext.h # note that global/... hasn't been updated recently -rw-r--r-- 1 root root 44502 Aug 17 03:53 /usr/lib64/opengl/global/include/GL/glxext.h -rw-r--r-- 1 root root 16906 Nov 19 17:27 /usr/lib64/opengl/xorg-x11/include/GL/glx.h $ echo '#include <GL/glx.h>' | cc -c -o/dev/null -xc - In file included from /usr/include/GL/glx.h:332:0, from <stdin>:1: /usr/include/GL/glxext.h:682:24: error: expected declaration specifiers or '...' before '*' token /usr/include/GL/glxext.h:683:67: error: unknown type name 'GLXContextID' emerge --info: Portage 2.2.7 (default/linux/amd64, gcc-4.7.3, glibc-2.17, 3.10.7-gentoo-r1 x86_64) ================================================================= System uname: Linux-3.10.7-gentoo-r1-x86_64-Intel-R-_Core-TM-_i7-4770S_CPU_@_3.10GHz-with-gentoo-2.2 KiB Mem: 8122680 total, 1336664 free KiB Swap: 4193276 total, 4172692 free Timestamp of tree: Tue, 19 Nov 2013 07:15:01 +0000 ld GNU ld (GNU Binutils) 2.23.2 app-shells/bash: 4.2_p45 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.5-r4, 3.2.5-r3, 3.3.2-r2 dev-util/cmake: 2.8.12.1-r1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.13.4, 1.14 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.7.3-r1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.10 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo crossdev sunrise steam-overlay local Installed sets: @steam, @system ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA AdobeFlash-11.x" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=x86-64 -mtune=core-avx-i -mmmx -msse -msse2 -pipe -g -fno-strict-aliasing" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/dev /etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=x86-64 -mtune=core-avx-i -mmmx -msse -msse2 -pipe -g -fno-strict-aliasing" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--misspell-suggestions=n --autounmask=n --quiet-build=n" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs collision-protect distlocks ebuild-locks fixlafiles merge-sync news preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.jaist.ac.jp/pub/Linux/Gentoo" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="-O --no-human-readable" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/crossdev /var/lib/layman/sunrise /var/lib/layman/steam /usr/local/portage" SYNC="rsync://rsync.jp.gentoo.org/gentoo-portage" USE="aac alsa amd64 apng berkdb cjk cli crypt cxx dri dv dvd fortran gif iconv ipv6 joystick jpeg jpeg2k lame live mad mmx mp3 mudflap multilib ncurses nptl nptlonly ogg openmp oss perl png pv3 python quicktime readline scanner sdl session sse sse2 ssl theora tiff truetype unicode vdpau vorbis vpx win32codecs x264 xanim zlib" ABI_X86="32 64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby19 ruby18" SANE_BACKENDS="genesys" USERLAND="GNU" VIDEO_CARDS="nvidia vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, USE_PYTHON
This seems to be causing build failures for (nearly?) every package building against mesa headers, for users of proprietary drivers (fglrx, nvidia) and mesa-10.
*** Bug 491678 has been marked as a duplicate of this bug. ***
*** Bug 491632 has been marked as a duplicate of this bug. ***
What state should the links be in? Is there any easy work around by manually linking the correct files?
I haven't attempted to correct it so I can't say for sure, but presumably the links should all point to headers in the same directory.
Do the proprietary drivers ship a glxext.h? The eselect script seems to go on a file-by-file basis. If it can't find the file in /usr/lib/opengl/<requested-impl>/include/, it tries /usr/lib/opengl/global/include/, then finally /usr/lib/include/xorg-x11/include/. If this is the problem, it would be a simple fix in the eselect module to drop the extra path arguments to setup_includes_symlinks on line 258. I'm sure they were added for a reason, but I can't see how the resultant behavior (mixing files between implementations) would ever result in a working setup.
It looks like nvidia-drivers doesn't include any GL headers at all: $ ls /usr/lib/opengl/nvidia extensions/ lib/ $ equery f nvidia-drivers | grep '\.h$' $ Presumably the proper behavior in this case is to use xorg-x11 for all headers, not mix xorg-x11 and global. I haven't looked up the history, but is there even a need for global to exist at all? Do some other proprietary drivers provide partial header sets that need to be augmented by global/* headers?
The global include files have been around since the first revision of the first version of eselect-opengl (with a comment "# Install default glext.h"). Does anyone know what package contained opengl-update? Its revision history may show us why those files exist. In terms of contents, the global files seem to be quite different from the xorg-x11 ones. They both appear to have been based off the same file at some point in time, but they've diverged quite a bit since.
This is the commit log for the version of opengl-update that added the global implementation. It claims that the global files are a better glext.h implementation, that should be used unless implementations insist on shipping their own. (Better than what, I'm not sure). http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-base/opengl-update/files/opengl-update-1.8?hideattic=0&view=log
The ebuild and include files themselves suggest they're verbatim from the Khronos registry. The problem is that all of the other files (pulled from mesa) generally expected matched files for a particular version. Gentoo's already using mesa for all of the other files, and the present files included haven't been updated for a year. Rather than assuming that eselect-opengl should include registry files separately from mesa (which includes the files verbatim from Khronos as is required for a particular version of mesa), eselect-opengl should probably just trust that mesa will provide the relevant matching files if another implementation doesn't. Presently, neither AMD or Nvidia do, and both compile their own files (fgl_glxgears for instance) corrently only when the mesa header files are used. The glext.h/glxext.h included in eselect-gentoo aren't special, they're just old versions, that's all. There are probably historical reasons for including them , such that it looks like mesa included its own, custom version pre-Khronos, and I know extremely old drivers included their own 'standard' headers once upon a time, but the correct notion is likely now to simply include what mesa says if an implementation doesn't provide its own headers. Even pulling a full header set from Khronos for 'global' probably isn't sufficient if not updated very frequently. I think in this case, it makes sense to trust mesa as the fallback, so long as they're using Khronos/upstream properly. People using proprietary drivers, at current, have to eselect back to xorg-x11 every time when building anything that touches glx (at least), just to get the correct headers. Dropping the 'global' case (or at least the priority over mesa as a fallback) makes everything work correctly for me, at least.
Created attachment 366336 [details, diff] eselect-opengl-1.2.7.ebuild patch to remove "global" include files Patch is against 1.2.7, but I imagine the result would best be added as a new version.
Created attachment 366338 [details, diff] opengl.eselect patch to remove "global" include files Most likely the result of applying the patch needs to be a new file in distfiles.
(In reply to Taahir Ahmed from comment #12) > Created attachment 366338 [details, diff] [details, diff] > opengl.eselect patch to remove "global" include files > > Most likely the result of applying the patch needs to be a new file in > distfiles. The files (glext.h and glxext.h) in global/ directory are provided by eselect-opengl. Although they are provided by Khronos, current mesa ships newer versions of these files. glext: #define GL_GLEXT_VERSION 85 (eselect-opengl 1.2.7) vs. #define GL_GLEXT_VERSION 20130708 (mesa 9.2.6) vs. #define GL_GLEXT_VERSION 20131008 (mesa 10 git) vs. #define GL_GLEXT_VERSION 20131212 (mesa git) glxext: #define GLX_GLXEXT_VERSION 34 (eselect-opengl 1.2.7) vs. #define GLX_GLXEXT_VERSION 33 (mesa 9.2.6) vs. #define GLX_GLXEXT_VERSION 20131008 (mesa 10 git) vs. #define GLX_GLXEXT_VERSION 20131008 (mesa git) Given that nvidia-drivers don't provide headers, IMO the correct approach would be to use implementation headers first and fallback to global/ second. Or at least update the headers installed by eselect-opengl.
The behavior this patch would introduce would be to use the xorg-x11 headers as the fallback. The global headers only include glext.h and glxext.h, so opengl.eselect is always taking some files from xorg-x11 (as indicated by the links shown in the first comment). If this is the case, why keep global headers at all? I'm not objecting to it in principle, just wondering.
Might be related: https://bugs.freedesktop.org/show_bug.cgi?id=70591 So its seems the GLXContextID typedef temporaryly got removed from glx.h, but then put back there (Mesa commit f425d56ba41382be04366d011536ee78a03a2f33). As 347f1493320e1bc2194c70d4d66bfe2b5883bf1e that revert is also part of the mesa-10 branch, but that commit was made after the release of 10.0.1.
(In reply to Torsten Kaiser from comment #15) > Might be related: https://bugs.freedesktop.org/show_bug.cgi?id=70591 > > So its seems the GLXContextID typedef temporaryly got removed from glx.h, > but then put back there (Mesa commit > f425d56ba41382be04366d011536ee78a03a2f33). > As 347f1493320e1bc2194c70d4d66bfe2b5883bf1e that revert is also part of the > mesa-10 branch, but that commit was made after the release of 10.0.1. Seems this commit should also fix bug 491660 and bug 491664
I've committed mesa-10.0.2-r1 with a patch that I believe fixes this issue. Please test.
* Applying mesa-10.0.2-update-glxext.h.patch ... * Failed Patch: mesa-10.0.2-update-glxext.h.patch ! * ( /usr/portage/media-libs/mesa/files/mesa-10.0.2-update-glxext.h.patch ) That didn't go so well.
same here(In reply to Roc Vallès from comment #18) > * Applying mesa-10.0.2-update-glxext.h.patch ... > > * Failed Patch: mesa-10.0.2-update-glxext.h.patch ! > * ( /usr/portage/media-libs/mesa/files/mesa-10.0.2-update-glxext.h.patch ) > > That didn't go so well. same for me
and here
Sorry about that. It should be fixed now. Please give it another shot.
For me it still fails: relevant part from mesa-10.0.2-update-glxext.h.patch.out: PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < '/var/repositories/gentoo/media-libs/mesa/files/mesa-10.0.2-update-glxext.h.patch' ============================================= checking file include/GL/glxext.h Hunk #1 FAILED at 33. 1 out of 4 hunks FAILED
(In reply to Matt Turner from comment #21) > Sorry about that. It should be fixed now. Please give it another shot. Still broken for me. I think the problem is that CVS is mucking with the $$ tags in the diff when you commit it.
Fails here getting this: # cat /var/tmp/portage/media-libs/mesa-10.0.2-r1/temp/mesa-10.0.2-update-glxext.h.patch.out ***** mesa-10.0.2-update-glxext.h.patch ***** PWD: /var/tmp/portage/media-libs/mesa-10.0.2-r1/work/Mesa-10.0.2 ============================================= PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < '/usr/portage/media-libs/mesa/files/mesa-10.0.2-update-glxext.h.patch' ============================================= can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -ur Mesa-10.0.2.orig/include/GL/glxext.h Mesa-10.0.2/include/GL/glxext.h |--- Mesa-10.0.2.orig/include/GL/glxext.h 2014-01-26 10:43:47.082996517 -0800 |+++ Mesa-10.0.2/include/GL/glxext.h 2014-01-26 10:44:19.378000149 -0800 -------------------------- No file to patch. Skipping patch. 4 out of 4 hunks ignored patch program exited with status 1 ============================================= PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < '/usr/portage/media-libs/mesa/files/mesa-10.0.2-update-glxext.h.patch' ============================================= patching file include/GL/glxext.h Hunk #1 FAILED at 33. 1 out of 4 hunks FAILED -- saving rejects to file include/GL/glxext.h.rej patch program exited with status 1 ============================================= PATCH COMMAND: patch -p2 -g0 -E --no-backup-if-mismatch < '/usr/portage/media-libs/mesa/files/mesa-10.0.2-update-glxext.h.patch' ============================================= can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -ur Mesa-10.0.2.orig/include/GL/glxext.h Mesa-10.0.2/include/GL/glxext.h |--- Mesa-10.0.2.orig/include/GL/glxext.h 2014-01-26 10:43:47.082996517 -0800 |+++ Mesa-10.0.2/include/GL/glxext.h 2014-01-26 10:44:19.378000149 -0800 -------------------------- No file to patch. Skipping patch. 4 out of 4 hunks ignored patch program exited with status 1 ============================================= PATCH COMMAND: patch -p3 -g0 -E --no-backup-if-mismatch < '/usr/portage/media-libs/mesa/files/mesa-10.0.2-update-glxext.h.patch' ============================================= can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -ur Mesa-10.0.2.orig/include/GL/glxext.h Mesa-10.0.2/include/GL/glxext.h |--- Mesa-10.0.2.orig/include/GL/glxext.h 2014-01-26 10:43:47.082996517 -0800 |+++ Mesa-10.0.2/include/GL/glxext.h 2014-01-26 10:44:19.378000149 -0800 -------------------------- No file to patch. Skipping patch. 4 out of 4 hunks ignored patch program exited with status 1 ============================================= PATCH COMMAND: patch -p4 -g0 -E --no-backup-if-mismatch < '/usr/portage/media-libs/mesa/files/mesa-10.0.2-update-glxext.h.patch' ============================================= can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -ur Mesa-10.0.2.orig/include/GL/glxext.h Mesa-10.0.2/include/GL/glxext.h |--- Mesa-10.0.2.orig/include/GL/glxext.h 2014-01-26 10:43:47.082996517 -0800 |+++ Mesa-10.0.2/include/GL/glxext.h 2014-01-26 10:44:19.378000149 -0800 -------------------------- No file to patch. Skipping patch. 4 out of 4 hunks ignored patch program exited with status 1
Wow. Fuck CVS. Committed the patch without the hunk that CVS insists on modifying.
(In reply to Matt Turner from comment #25) > Wow. Fuck CVS. > Committed the patch without the hunk that CVS insists on modifying. Why don't you disable keyward expansion for *.patch files?
(In reply to Sven from comment #26) > Why don't you disable keyward expansion for *.patch files? Or not use CVS, but I guess that's too easy an answer (: The patch applies cleanly now, and my #include <glx.h> test from comment #0 also passes, so it looks like this should fix the bug.
(In reply to Andrew Church from comment #27) > The patch applies cleanly now, and my #include <glx.h> test from comment #0 > also passes, so it looks like this should fix the bug. Thanks! After all the reports of the patch not applying, only one report of it actually working...
*** Bug 491660 has been marked as a duplicate of this bug. ***
