Bug#867188: glx-alternative-nvidia: libEGL.so and libEGL.so.1 point to different libraries

Luca Boccassi luca.boccassi at gmail.com
Tue Jul 4 22:48:15 UTC 2017


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20170704/7b09946a/attachment-0001.sig>


More information about the pkg-nvidia-devel mailing list