On Tue, 2017-07-04 at 21:36 +0600, Aleksandr Mezin wrote: > Package: glx-alternative-nvidia > Version: 0.7.4 > Severity: normal > > Dear Maintainer, > > On my system /usr/lib/x86_64-linux-gnu/libEGL.so and /usr/lib/x86_64- > linux- > gnu/libEGL.so.1 point to different libraries: > /usr/lib/x86_64-linux-gnu/libEGL.so -> /etc/alternatives/glx-- > libEGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux- > gnu/libEGL.so > /usr/lib/x86_64-linux-gnu/libEGL.so.1 -> /etc/alternatives/glx-- > libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux- > gnu/nvidia/libEGL.so.1 > > The same is true for libGL: > /etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> /usr/lib/mesa- > diverted/x86_64-linux-gnu/libGL.so > /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> > /usr/lib/x86_64-linux- > gnu/nvidia/libGL.so.1 > > and libGLESv2: > /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> > /usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2 > /etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> > /usr/lib/mesa- > diverted/x86_64-linux-gnu/libGLESv2.so > > So applications that try to dlopen() libEGL.so, libGL.so, or > libGLESv2.so load > wrong library and fall back to slow softpipe. > > update-glx is in "automatic" mode, 0 = /usr/lib/nvidia: > > $ sudo update-glx --config glx > There are 3 choices for the alternative glx (providing /usr/lib/glx). > > Selection Path Priority Status > ------------------------------------------------------------ > * 0 /usr/lib/nvidia 100 auto mode > 1 /usr/lib/mesa-diverted 5 manual mode > 2 /usr/lib/nvidia 100 manual mode > 3 /usr/lib/nvidia/bumblebee 95 manual mode
Hi, This is intended IIRC. That's because application should build and link against the Mesa libraries, not the NVIDIA ones. Applications that manually dlopen() should load the versioned SO as well, as if/when the ABI compatibility breaks the application is likely going to break too. Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
