I'm trying to install modular xorg-server-1.0.2-r7, which pulls in eselect-opengl-1.0.3. The last sets symlinks to /usr/lib32/opengl include files and the compilation of xorg-server fails $ eselect opengl list Available OpenGL implementations: [1] xorg-x11 * $ eselect opengl set xorg-x11 $ ls -l /usr/include/GL/glext.h lrwxrwxrwx 1 root root 40 Jul 3 14:43 /usr/include/GL/glext.h -> /usr/lib32/opengl/global/include/glext.h and the rest 6 symplinks set in /usr/include/GL points to 32 bit realization. $ emerge xorg-server ...... glxcmds.c:1796: error: `xGLXQueryHyperpipeNetworkSGIXReq' undeclared (first use in this function) glxcmds.c:1796: error: (Each undeclared identifier is reported only once glxcmds.c:1796: error: for each function it appears in.) glxcmds.c:1796: error: `req' undeclared (first use in this function) glxcmds.c:1796: error: syntax error before ')' token ....... Manual relinking of these include files to /usr/lib64/opengl does not help, since eselect seems to be called during emerging of the xorg-server $ emerge --info Portage 2.1-r1 (default-linux/amd64/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.14-gentoo-r5 x86_64) ================================================================= System uname: 2.6.14-gentoo-r5 x86_64 AMD Opteron(tm) Processor 848 Gentoo Base System version 1.6.15 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/X11/xkb /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=opteron -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical" FEATURES="autoconfig buildpkg distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X avi berkdb bitmap-fonts cli crypt cups dlloader eds emboss encode foomaticdb fortran gif gtk gtk2 isdnlog jpeg lzw lzw-tiff mp3 mpeg ncurses nls nptl pam pcre pdflib perl png pppd python qt qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd tiff truetype-fonts type1-fonts unicode xorg xpm zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_mach64 video_cards_vesa" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
A workaround, edit /usr/share/eselect/libs/multilib.bash and change ES_VALID_MULTILIB_DIRS="lib lib32 lib64" to ES_VALID_MULTILIB_DIRS="lib32 lib lib64" This seems to allow xorg-xserver to compile, for example. [The workaround just has the effect that the list_libdirs loops in eselect-opengl are done in 32-bit and then 64-bit order. For the loop which does the include directories [which ignores the lib64 because it is a link to lib] this means the 32 bit links are done first, then the "correct" links are done afterwards rather than doing 64-bit and then 32-bit] It's all too ugly, on all fronts, to find someone to blame or suggest a better fix :)
(In reply to comment #1) This is actualy the least ugly workaround I was able to find :) Indeed, it seems just wrong to have lib32 in priority position over lib
*** Bug 139695 has been marked as a duplicate of this bug. ***
*** Bug 139691 has been marked as a duplicate of this bug. ***
*** Bug 139908 has been marked as a duplicate of this bug. ***
I guess this bug is not due to eselect-opengl at all. From comment #2 and conversation with Stuart, i deduce that people who hit this bug have acutally a broken setup: People, please check for your library setup. You should have /lib symlink to /lib64 /lib32 directory /lib64 directory Same goes for /usr/lib* /usr/lib symlink to /usr/lib64 /usr/lib32 directory /usr/lib64 directory Everything else is broken and should be fixed. AMD64 team will soon publish a guide how to do this. Sorry for all the inconvenience. If anybody is hitting the same bug with eselect-opengl and has a sane libdir setup as listed above, please file a new bug.
(In reply to comment #7) > I guess this bug is not due to eselect-opengl at all. > From comment #2 and conversation with Stuart, i deduce that people who > hit this bug have acutally a broken setup: > > People, please check for your library setup. You should have > /lib symlink to /lib64 > /lib32 directory > /lib64 directory > > Same goes for /usr/lib* > /usr/lib symlink to /usr/lib64 > /usr/lib32 directory > /usr/lib64 directory > > Everything else is broken and should be fixed. AMD64 team will soon publish > a guide how to do this. Sorry for all the inconvenience. > > If anybody is hitting the same bug with eselect-opengl and has a sane libdir > setup as listed above, please file a new bug. > Yes indeed, I have lib - directory lib32 - directory lib64 - symlink to lib and /usr/lib - directory /usr/lib32 - directory /usr/lib64 - symlink to /usr/lib However, I vaguely remember that when 2006.0 (2005.1 ??) profile appeared there was some discussion that the directory structure is changed and that 2006.0 is converted to a 'proper' one. Isn't it what you propose is what was in place before the recent profiles ?
> However, I vaguely remember that when 2006.0 (2005.1 ??) profile appeared there > was some discussion that the directory structure is changed and that 2006.0 is > converted to a 'proper' one. Isn't it what you propose is what was in place > before the recent profiles ? > I may not remember the dates correctly, and I did not find an explicit statement on Gentoo website as to what structure is considered standard, but a web search shows that there was a lot of heated discussions 1-1.5 years ago whether lib should be real and lib64 symlink or wise-versa (with the reference to AMD64 ABI guidelines). Moreover plenty of Web sites claim that Redhat and Suse use real lib64 and lib is a symlink, while Gentoo, Debian and Ubintu use an opposite convention. It would be good to know when Gentoo-amd64 changed its mind, since I was just dutifully updating profiles, never manually changing the directory structure.
looks like bug 132135 to me *** This bug has been marked as a duplicate of 132135 ***
