Bugzilla Bug 138766

An abbreviated output is below.  The full output plus emerge --info is
attached.  I have tried re-emerging eselect eselect-config nvidia-glx protogl
mesa xorg-server and making the xorg glx headers symlinks to those in
/usr/.../OpenGL.  None of this worked.

if /bin/sh ../../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc
-DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../include
-I../../include -I../../include -I../../include -I../../GL/include
-I../../hw/xfree86/os-support   -DHAVE_DIX_CONFIG_H
-I/var/tmp/portage/xorg-server-1.0.2-r7/work/Mesa-6.4.2/include -DXFree86Server
-DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN
-DHAS_STICKY_DIR_BIT   -I../../include -I../../include -I../../Xext
-I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi
-I../../miext/shadow  -I../../miext/damage -I../../render -I../../randr
-I../../fb -I../../lbx   -O2 -MT glxcmdsswap.lo -MD -MP -MF
".deps/glxcmdsswap.Tpo" -c -o glxcmdsswap.lo glxcmdsswap.c; \
then mv -f ".deps/glxcmdsswap.Tpo" ".deps/glxcmdsswap.Plo"; else rm -f
".deps/glxcmdsswap.Tpo"; exit 1; fi
 x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include
-I../../include -I../../include -I../../include -I../../include -I../../include
-I../../GL/include -I../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H
-I/var/tmp/portage/xorg-server-1.0.2-r7/work/Mesa-6.4.2/include -DXFree86Server
-DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN
-DHAS_STICKY_DIR_BIT -I../../include -I../../include -I../../Xext
-I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi
-I../../miext/shadow -I../../miext/damage -I../../render -I../../randr
-I../../fb -I../../lbx -O2 -MT glxcmds.lo -MD -MP -MF .deps/glxcmds.Tpo -c
glxcmds.c  -fPIC -DPIC -o .libs/glxcmds.o
glxcmds.c: In function `__glXBindSwapBarrierSGIX':
glxcmds.c:1749: warning: cast to pointer from integer of different size
glxcmds.c: In function `__glxQueryHyperpipeNetworkSGIX':
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
glxcmds.c:1797: error: `xGLXQueryHyperpipeNetworkSGIXReply' undeclared (first
use in this function)
glxcmds.c:1812: error: `reply' undeclared (first use in this function)
glxcmds.c:1825: error: `sz_xGLXQueryHyperpipeNetworkSGIXReply' undeclared
(first use in this function)
glxcmds.c: In function `__glxDestroyHyperpipeConfigSGIX':
glxcmds.c:1836: error: `xGLXDestroyHyperpipeConfigSGIXReq' undeclared (first
use in this function)
glxcmds.c:1836: error: `req' undeclared (first use in this function)
glxcmds.c:1837: error: syntax error before ')' token
glxcmds.c:1838: error: `xGLXDestroyHyperpipeConfigSGIXReply' undeclared (first
use in this function)
glxcmds.c:1851: error: `reply' undeclared (first use in this function)
glxcmds.c:1863: error: `sz_xGLXDestroyHyperpipeConfigSGIXReply' undeclared
(first use in this function)
glxcmds.c: In function `__glxQueryHyperpipeConfigSGIX':
glxcmds.c:1871: error: `xGLXQueryHyperpipeConfigSGIXReq' undeclared (first use
in this function)
glxcmds.c:1871: error: `req' undeclared (first use in this function)
glxcmds.c:1872: error: syntax error before ')' token
glxcmds.c:1873: error: `xGLXQueryHyperpipeConfigSGIXReply' undeclared (first
use in this function)
glxcmds.c:1889: error: `reply' undeclared (first use in this function)
glxcmds.c:1904: error: `sz_xGLXQueryHyperpipeConfigSGIXReply' undeclared (first
use in this function)
glxcmds.c: In function `__glxHyperpipeConfigSGIX':
glxcmds.c:1915: error: `xGLXHyperpipeConfigSGIXReq' undeclared (first use in
this function)
glxcmds.c:1915: error: `req' undeclared (first use in this function)
glxcmds.c:1916: error: syntax error before ')' token
glxcmds.c:1917: error: `xGLXHyperpipeConfigSGIXReply' undeclared (first use in
this function)
glxcmds.c:1935: error: `reply' undeclared (first use in this function)
glxcmds.c:1949: error: `sz_xGLXHyperpipeConfigSGIXReply' undeclared (first use
in this function)
make[2]: *** [glxcmds.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
 x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include
-I../../include -I../../include -I../../include -I../../include -I../../include
-I../../GL/include -I../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H
-I/var/tmp/portage/xorg-server-1.0.2-r7/work/Mesa-6.4.2/include -DXFree86Server
-DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN
-DHAS_STICKY_DIR_BIT -I../../include -I../../include -I../../Xext
-I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi
-I../../miext/shadow -I../../miext/damage -I../../render -I../../randr
-I../../fb -I../../lbx -O2 -MT glxcmdsswap.lo -MD -MP -MF .deps/glxcmdsswap.Tpo
-c glxcmdsswap.c  -fPIC -DPIC -o .libs/glxcmdsswap.o
make[2]: Leaving directory
`/var/tmp/portage/xorg-server-1.0.2-r7/work/xorg-server-1.0.2/GL/glx'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xorg-server-1.0.2-r7/work/xorg-server-1.0.2/GL'
make: *** [all-recursive] Error 1

!!! ERROR: x11-base/xorg-server-1.0.2-r7 failed.

reopen with emerge info

Created an attachment (id=90640) [edit]
Full compile output plus emerge --info

Part of the middle was removed because it was a little too large.

reporter: please reopen that bug
i've got the same bug
i tried to unmerge nvidia-glx and it didn't help
any ideas?
(amd64 too)

I have this exactly same problem on amd64 platform as well. I couldn't find any
workarounds either by removing or re-emerging packages.

No resolution.  emerge --info in attachment.

ok, unmerging emul-linux-x86-xlibs (2.2.2!) helped
see bugs: 111877, 109922

The problem is that '/usr/include/GL/glxproto.h' is symlinked to
'//usr/lib32/opengl/xorg-x11/include/glxproto.h'. This should be
'/usr/lib/opengl/xorg-x11/include/glxproto.h' of course. The symlink is created
by 'eselect opengl set xorg-x11 --impl-headers', which is called from the
ebuild, so manually correcting the symlink does not work.

The responsible code is in '/usr/share/eselect/modules/opengl.eselect'. As a
temporary fix you can change line 120 in that file from "[[ -d
${PREFIX}/${libdir}/opengl ]] || continue" into "continue". Hopefully some
gentoo-dev can provide a proper fix with this info.

I had this same problem on an AMD64 with NVIDIA drivers.

I was able to solve it when I found bug #109922 (in particular comments 18 and
19).

To solve it you don't have to edit eselect code. I got xorg-server to compile
by emerging:

emul-linux-x86-xlibs-7.0-r1
emul-linux-x86-baselibs-2.5


Which are both still marked as unstable (emul-linux-x86-baselibs-2.5 is a
dependency of emul-linux-x86-xlibs-7.0-r1).

Unless you depend on the fixed version or block the broken version, people will
continue to hit this.

AMD64 team, suggested solution? At least get emul-xlibs stable, not sure what
else should be done.

no way to stablize emul-xlibs-7.0 before bug 136944 is fixed.

*** Bug 138850 has been marked as a duplicate of this bug. ***

(In reply to comment #12)
> *** Bug 138850 has been marked as a duplicate of this bug. ***
> 

hi jakub:  do you know everything?  :-).  thanks.  I would also strongly
suggest adding blockers to packages (specifically, here,
emul-linux-x86-xlibs-2.2.2) known to block the emergence of xorg-x11 under
amd64.

regards,

/iaw

(In reply to comment #9)
> Unless you depend on the fixed version or block the broken version, people will
> continue to hit this.

Indeed, I just got hit by this, more than a week after xorg-x11 for amd64
'stabilized'. This is a problem that was known since the beginning of april
(see bug 109922).

For me, this is the second stable xorg-x11 emerge that causes trouble on amd64
recently because of library location troubles. I advise keeping xorg-x11
ebuilds in unstable somewhat longer than their x86 counterparts and I would
greatly appreciate -- as Jacob suggested -- that blocks are put in place as
fast as a problem is diagnosed. Adding a note to the upgrade guide could also
help.

Sorry for the complaint, I do appreciate the effort of the developers, but I
think keeping things unstable until all known problems are addressed is
something gentoo users should be able to expect. Finding workarounds in
bugreports, as I'm doing now, is something for unstable packages.

minor xorg 7 question (not related).  is /usr/X11R6 going to become /usr/X11R7
?

/iaw

(In reply to comment #15)
> minor xorg 7 question (not related).  is /usr/X11R6 going to become /usr/X11R7

No, it's becoming /usr.

*** Bug 140959 has been marked as a duplicate of this bug. ***

emul-xlibs is stable, assume it's fixed

actually, it isn't

Always nice to be hit by a bug in a "stable" package. Especially nice if the
package is the X server, since you are basically forced to update it with any
"emerge --update xxxxx" command.
Is gentoo now also shipping (i.e. making stable) with known major bugs?

Ob-Solution: 
If your /usr/lib64 is a symlink to /usr/lib (which seems to be one of the
reasons of this bug), you have to change it around (see bug 109922 comments 11
and 14). So do
rm /usr/lib64
mv /usr/lib /usr/lib64
ln -s /usr/lib64 /usr/lib

(In reply to comment #19)
> actually, it isn't
> 

What's wrong now?

(In reply to comment #18)
> emul-xlibs is stable, assume it's fixed

(In reply to comment #19)
> actually, it isn't 

i hope that makes it clear :)

Oooh, you meant it's not stable, not that it *is* stable but doesn't fix the
problem.  I get it :)

*** Bug 142081 has been marked as a duplicate of this bug. ***

emul-xlibs really is now stable, fixed.