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

[Luca Boccassi]

On Fri, 2017-09-29 at 15:52 +0200, Bernd Vaske wrote:
> 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.

IIRC glvnd is for the server-side, but for optimus a client-side
solution is also needed (which is what primus provides). I've seen
talks from Nvidia about a similar client-side solution specifically for
this case, but I don't think there's anything concrete yet,
unfortunately.

> > 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.

Unfortunately the problem can't be reproduced on Stretch given there's
no glvnd there. At the moment I do not have a Sid installation on
hardware that supports optimus, unfortunately, sorry. I'll try to find
time to install it on one of my laptops in the next couple of weeks.

Instead of symlinking the file, could you please try to edit the
LibraryPath line in /etc/bumblebee/bumblebee.conf and add

:/usr/lib/x86_64-linux-gnu:/usr/lib/i386-linux-gnu

to it? Then systemctl restart bumblebeed.service

It would be tricky to ship it in the packages, as without the glvnd it
would actually break it.

What if, as an interim solution to avoid breakages, I added a Conflicts
with libgl1-glvnd-nvidia-glx on primuslibs, so that the non-glvnd
packages will get pulled in automatically when using bumblebee?

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20171003/3a0c47d7/attachment.sig>