mesa-11.0.6 install libGL.so and others to /usr/lib64 instead of moving it to /usr/lib64/opengl/xorg-x11/lib/ for switching by eselect opengl. Reproducible: Always Actual Results: some opengl applications don't work with nvidia-drivers wihtout LD_LIBRARY_PATH to nvidia libGL.so
Created attachment 418372 [details] corrected ebuild for mesa
Newer versions of eselect-opengl (>=1.3) should handle this, it doesn't use symlinks anymore but manipulates libary paths in /etc/env.d/000opengl and /etc/X11/xorg.conf.d/20opengl.conf Do you have this newer eselect?
(In reply to Ben Kohler from comment #2) > Newer versions of eselect-opengl (>=1.3) should handle this, it doesn't use > symlinks anymore but manipulates libary paths in /etc/env.d/000opengl and > /etc/X11/xorg.conf.d/20opengl.conf > > Do you have this newer eselect? i have eselect-opengl-1.3.1-r4, but a half (only half, but i don't understand a reason) of my programs don't work with it. i try to rebuild its, reboot, but i only have: libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast XRequest.151: BadValue (integer parameter out of range for operation) 0x0 XRequest.151: GLXBadContext 0x600002b XRequest.151: 0 0x0 XRequest.151: GLXBadDrawable 0x6000006 XRequest.151: GLXBadDrawable 0x6000006 but when i manualy set LD_LIBRARY_PATH to nvidia libs i cause its work. when i reemerge mesa with my patch all work well. P.S. I found similar problems in forum with steam.
i found the source of the problem. the reason is that libtool generate script to start some tests from build dirs without installing and add LD_LIBRARY_PATH=...:/usr/lib64:.... to it in some cases. This is not mesa bug. it may be libtool bug or feature: add some system library paths to local scripts.
