Bug#876033: primusrun doesn't find libGL.so.1

[Bernd Vaske]

On Mon, 25 Sep 2017 20:50:53 +0200 Andreas Beckmann <anbe at debian.org> wrote:
> [ Cc:ing the libglvnd maintainer ]
> 
> On 09/25/2017 04:38 PM, Emilio J. Padrón wrote:
> > I obtain the same error when trying primusrun (or optirun) in my system:
> > 
> > % primusrun glxinfo
> > /usr/bin/primusrun: line 41: warning: command substitution: ignored null byte in input
> > primus: fatal: failed to load any of the libraries:
> > /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1:/usr/lib/i386-linux-gnu/nvidia/libGL.so.1:/usr/lib/nvidia/libGL.so.1
> > /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
> > /usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
> > /usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such file or directory
> > 
> > The '__GLVND_DISALLOW_PATCHING=1' workaround did not work for me :-?
> > (same error messages).
> 
> The question is: how should primusrun/optirun work in a GLVND
> environment? There is no longer the "vendor" libGL.so.1 that has to be
> loaded instead of the system libGL.so.1
> As I understand it, GLVND is supposed to provide a better solution to
> the underlying problem addressed by primusrun/optirun.

Doesn't it only address part of the problem? Don't see a lot in regards 
of turning the dedicated card on/off.
The dispatching to a specific vendor GLX is per x screen? At least thats 
how it is described in https://github.com/NVIDIA/libglvnd. Which seems 
to mirror the nvidia PRIME way.

So maybe primusrun/optirun will still bring up the card but only "fake" 
the context to be nvidia for a specific application and thus forcing the 
gldispatch to divert to the nvidia gl.

> Note: if libgl1-nvidia-glvnd-glx is used (instead of libgl1-nvidia-glx)
> and libgl1 (from src:libglvnd) is installed instead of
> libgl1-glvnd-nvidia-glx, there is no longer a nvidia-provided
> /usr/lib/*/nvidia/libGL.so.1
> 
> (Note for Timo: for the nvidia drivers we still need to divert the
> system libGL.so.1 (and much more) since the legacy 304xx, 340xx drivers
> don't support GLVND and we therefore still need to use the nested
> alternatives, and we want to have them co-installable with the current
> drivers)
> 
> > By the way, I suppose it is not really related, but I'm not able to install
> > nvidia glvnd packages, libgl1-glvnd-nvidia-glx 375.82-4 and
> > libglvnd0-nvidia 375.82-4, due to dependency problems. The metapackage
> > libgl1-nvidia-glvnd-glx 375.82-4 is installed ok, since the libgl1
> > dependency is provided by other packages. Is it also a bug? :-?
> 
> That is intentional to allow the nvidia packages into testing which
> still has mesa 13.x and no libglvnd. You should be fine with the libgl1,
> ... packages from src:libglvnd in sid.
> 
> 
> Andreas

BTW the workaround I posted still seems to work. But you must not forget 
to link the libGL.so.1 into the nvidia subdirectory in addition to the 
__GLVND_DISALLOW_PATCHING=1.