On 2018-11-05 13:45, Julian Gilbey wrote: > On Mon, Nov 05, 2018 at 10:43:44AM +0100, Andreas Beckmann wrote: >> Control: tag -1 wontfix >> >> On 2018-11-05 01:17, Julian Gilbey wrote: >>> So the pragmatic way to fix it would be to symlink libGL.so to the >>> NVIDIA libGL.so... (and presumably the other related .so libraries) >>> when glx-diversions is used. Because having libGL.so.1 pointing to >>> one version of the library and libGL.so pointing to an incompatible >>> version is causing this crash. >>> >>> Please could you therefore modify glx-diversions to ensure that the >>> unversioned libGL.so points to the same location as the versioned >>> libGL.so.1 (and the others too: libEGL.so, libGLESv1_CM.so and >>> libGLESv2.so). >> >> Stuff that dlopens the .so files is broken. They should dlopen the .so.1 >> (or thatever the soversion is). > > By this argument, surely there should not be a libGL.so on the system > at all?
The .so file is for use by the linker. Not for runtime. > And it also does not address the serious issue that libGL.so > points to a different library from libGL.so.1. > > The discussions online show that this is an issue which has been > around for years. The solution is simple. Does your testcase run under bumblebee? Andreas