I was cross-compiling x11-aps/xdriinfo-1.0.2, and it failed saying = checking for library containing glXGetProcAddressARB... no configure: error: cannot find GL library - make sure Mesa or other OpenGL package is installed = $ROOT/usr/lib/libGL.so contains glXGetProcAddressARB, which was odd... however, $ROOT/usr/lib/libGL.so was a symbolic link to a file of x86 architecture! Booo! I found that very odd, because I just installed x11-libs/mesa and had to manually correct the symbolic link layout that eselect-opengl messed up too, then I noticed that eselect opengl was called during the xdriinfo-1.0.2 ebuild, which explains why it was messed up again. The pattern is this: /usr/armv5tel-softfloat-linux-gnueabi/usr/lib/libGL.so -> /usr/lib/opengl/xorg-x11/lib/libGL.so should be (relative to /usr/armv5tel-softfloat-linux-gnueabi/usr/lib) libGL.so -> opengl/xorg-x11/lib/libGL.so Yes, that's right, eselect-opengl will try to create a symbolic link from the libGL.so in / (of CBUILD architecture) to $ROOT/usr/lib, which is of $CHOST architecture. Instead, it should properly detect the $ROOT environment variable, which is set for cross-compilation, and make the symbolic link relative instead of absolute. Please make eselect-opengl respect the ROOT env variable and change libGL.so accordingly (i.e. relatively, not absolutely). Reproducible: Always
I noticed a similar issue when using something like ROOT=/myrootfs emerge -K <package>. The symlinks I ended up having looked like this: libdri.so -> /myrootfs/usr/lib/opengl/xorg-x11/extensions/libdri.so
Created attachment 203868 [details] Patch to opengl.eselect Use a relative path when creating symlinks
Fixed in 1.0.8. Thanks for report and for patch.
