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

[devfra]

On 18/10/17 13:09:06 CEST, Luca Boccassi wrote:
> On Wed, 2017-10-18 at 13:18 +0200, devfra wrote:
> > On 18/10/17 10:58:08 CEST, Luca Boccassi wrote:
> > > I think there's a couple missing i386 packages, try to install the
> > > nvidia-driver-libs:i386 metapackage to pull them in
> > 
> > Installing nvidia-driver-libs:i386 causes dependencies issues
> 
> What are the dependency issues?

The nvidia related packages on my systems are those pulled in by:
$ sudo apt install bumblebee-nvidia primus primus-libs:i386

Now, having just the packages above and their dependencies installed, if I try 
to install nvidia-driver-libs:i386 I obtain this output [0] from apt and 
aptitude. I pasted a couple of resolutions proposed by aptitude but, as I said 
in the previous message, I solved my issue by installing just the
libgl1-nvidia-glx:i386 package.

Thanks!

[0] https://paste.debian.net/hidden/26a0487a/

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

[Luca Boccassi]

On Wed, 2017-10-18 at 13:18 +0200, devfra wrote:
> On 18/10/17 10:58:08 CEST, Luca Boccassi wrote:
> > I think there's a couple missing i386 packages, try to install the
> > nvidia-driver-libs:i386 metapackage to pull them in
> 
> Installing nvidia-driver-libs:i386 causes dependencies issues but
> easily 
> resolvable. However I solved my issue by installing just
> libgl1-nvidia-glx:i386.

What are the dependency issues?

> Could it be useful to add this package as a dependency of primus-
> libs:i386? 
> Having the latter installed I do not expect to install other
> packages.
> 
> Thank you for your help!

Unfortunately we can't as Primus is in MAIN but nvidia-driver is in
NON-FREE. And more importantly Primus can work with Nouveau as well.

The nvidia-driver-libs metapackage is the right entry point, installing
the i386 version is the supported to way to run 32bit applications, as
they might be using not only GLX but also EGL and so on.

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

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

[devfra]

On 18/10/17 10:58:08 CEST, Luca Boccassi wrote:
> I think there's a couple missing i386 packages, try to install the
> nvidia-driver-libs:i386 metapackage to pull them in

Installing nvidia-driver-libs:i386 causes dependencies issues but easily 
resolvable. However I solved my issue by installing just
libgl1-nvidia-glx:i386.

Could it be useful to add this package as a dependency of primus-libs:i386? 
Having the latter installed I do not expect to install other packages.

Thank you for your help!

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

[Luca Boccassi]

On Tue, 2017-10-17 at 22:43 +0200, devfra wrote:
> On martedì 17 ottobre 2017 20:53:49 CEST Luca Boccassi wrote:
> > What's the output of:
> > 
> > dpkg -l | grep 375.82-5
> 
> $ dpkg -l | grep 375.82-5
> ii  libegl-nvidia0:amd64375.82-5   amd64   NVIDIA binary EGL
> library
> ii  libegl-nvidia0:i386 375.82-5   i386NVIDIA binary EGL
> library
> ii  libgl1-nvidia-glx:amd64 375.82-5   amd64   NVIDIA binary
> OpenGL/GLX...
> ii  libglx-nvidia0:amd64375.82-5   amd64   NVIDIA binary GLX
> library
> ii  libglx-nvidia0:i386 375.82-5   i386NVIDIA binary GLX
> library
> ii  libnvidia-eglcore:amd64 375.82-5   amd64   NVIDIA binary EGL
> core l...
> ii  libnvidia-eglcore:i386  375.82-5   i386NVIDIA binary EGL
> core l...
> ii  libnvidia-glcore:amd64  375.82-5   amd64   NVIDIA binary
> OpenGL/GLX...
> ii  libnvidia-glcore:i386   375.82-5   i386NVIDIA binary
> OpenGL/GLX...
> ii  libnvidia-ml1:amd64 375.82-5   amd64   NVIDIA Management
> Librar...
> ii  nvidia-alternative  375.82-5   amd64   allows the
> selection of ...
> ii  nvidia-egl-common   375.82-5   amd64   NVIDIA binary EGL
> driver...
> ii  nvidia-egl-icd:amd64375.82-5   amd64   NVIDIA EGL
> installable c...
> ii  nvidia-egl-icd:i386 375.82-5   i386NVIDIA EGL
> installable c...
> ii  nvidia-kernel-dkms  375.82-5   amd64   NVIDIA binary
> kernel mod...
> ii  nvidia-kernel-support   375.82-5   amd64   NVIDIA binary
> kernel mod...
> ii  nvidia-legacy-check 375.82-5   amd64   check for NVIDIA
> GPUs re...
> ii  nvidia-vdpau-driver:amd64   375.82-5   amd64   Video Decode and
> Present...
> ii  xserver-xorg-video-nvidia   375.82-5   amd64   NVIDIA binary Xorg
> driver
> 
> Thanks.

I think there's a couple missing i386 packages, try to install the
nvidia-driver-libs:i386 metapackage to pull them in

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

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

[devfra]

On martedì 17 ottobre 2017 20:53:49 CEST Luca Boccassi wrote:
> What's the output of:
> 
> dpkg -l | grep 375.82-5

$ dpkg -l | grep 375.82-5
ii  libegl-nvidia0:amd64375.82-5   amd64   NVIDIA binary EGL library
ii  libegl-nvidia0:i386 375.82-5   i386NVIDIA binary EGL library
ii  libgl1-nvidia-glx:amd64 375.82-5   amd64   NVIDIA binary OpenGL/GLX...
ii  libglx-nvidia0:amd64375.82-5   amd64   NVIDIA binary GLX library
ii  libglx-nvidia0:i386 375.82-5   i386NVIDIA binary GLX library
ii  libnvidia-eglcore:amd64 375.82-5   amd64   NVIDIA binary EGL core l...
ii  libnvidia-eglcore:i386  375.82-5   i386NVIDIA binary EGL core l...
ii  libnvidia-glcore:amd64  375.82-5   amd64   NVIDIA binary OpenGL/GLX...
ii  libnvidia-glcore:i386   375.82-5   i386NVIDIA binary OpenGL/GLX...
ii  libnvidia-ml1:amd64 375.82-5   amd64   NVIDIA Management Librar...
ii  nvidia-alternative  375.82-5   amd64   allows the selection of ...
ii  nvidia-egl-common   375.82-5   amd64   NVIDIA binary EGL driver...
ii  nvidia-egl-icd:amd64375.82-5   amd64   NVIDIA EGL installable c...
ii  nvidia-egl-icd:i386 375.82-5   i386NVIDIA EGL installable c...
ii  nvidia-kernel-dkms  375.82-5   amd64   NVIDIA binary kernel mod...
ii  nvidia-kernel-support   375.82-5   amd64   NVIDIA binary kernel mod...
ii  nvidia-legacy-check 375.82-5   amd64   check for NVIDIA GPUs re...
ii  nvidia-vdpau-driver:amd64   375.82-5   amd64   Video Decode and Present...
ii  xserver-xorg-video-nvidia   375.82-5   amd64   NVIDIA binary Xorg driver

Thanks.

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

[Luca Boccassi]

On Tue, 2017-10-17 at 17:08 +0200, devfra wrote:
> Hello
> 
> The new version of primus have arrived today in Testing, everything
> works but 
> there is still a problem with the 32 bit version of LibGL.so.1.
> 
> I have a couple of 32-bit only applications that I run with wine,
> they give me 
> the following message:
> 
> 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: wrong ELF class:
> ELFCLASS64
> /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
> 
> Other 64 bit applications work with bumblebee as expected.

What's the output of:

dpkg -l | grep 375.82-5

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

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

[devfra]

Hello

The new version of primus have arrived today in Testing, everything works but 
there is still a problem with the 32 bit version of LibGL.so.1.

I have a couple of 32-bit only applications that I run with wine, they give me 
the following message:

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: wrong ELF class: ELFCLASS64
/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

Other 64 bit applications work with bumblebee as expected.

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

[Luca Boccassi]

On Wed, 2017-10-11 at 11:57 +0200, Andreas Beckmann wrote:
> On 10/11/2017 11:46 AM, Luca Boccassi wrote:
> > Andreas,
> > 
> > Long term, the only easy to maintain solution I can see (until
> > there is
> > proper support upstream for GLVND) would be to change the config in
> > a
> > postinst, depending on what package is installed. But that feels
> > very
> > wrong (changing config files) and very fragile.
> > What do you think?
> 
> Clear NACK for modifying conffiles. You would also need triggers to
> change this if some package is installed/removed later on.

Yep fully agree.

> I think primus needs two searchpatch variables (classic and glvnd)
> and
> needs to detect at runtime which one to use. Well, the second one
> could
> be "empty", since it uses system libs instead of driver dependent
> ones.
> How ever this runtime detection could look like.

The additional problem is that the change would involve bumblebee too,
since that's what sets up these paths.

Given it's a non-trivial amount of work, I wonder if it's better to
keep the workaround in place (assuming it doesn't cause problems) and
then wait for server-side GLVND to happen?

I've seen movement in the past few weeks, apparently support in Xorg is
about to land:

https://github.com/kbrenneman/libglvnd/commits/server-libglx-tag-data
https://www.phoronix.com/scan.php?page=news_item=NVIDIA-XDC17-GLVND
https://www.phoronix.com/scan.php?page=news_item=Xorg-Server-1.20-Features
https://lists.x.org/archives/xorg-devel/2017-July/054118.html

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

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

[Andreas Beckmann]

On 10/11/2017 11:46 AM, Luca Boccassi wrote:
> Andreas,
> 
> Long term, the only easy to maintain solution I can see (until there is
> proper support upstream for GLVND) would be to change the config in a
> postinst, depending on what package is installed. But that feels very
> wrong (changing config files) and very fragile.
> What do you think?

Clear NACK for modifying conffiles. You would also need triggers to
change this if some package is installed/removed later on.

I think primus needs two searchpatch variables (classic and glvnd) and
needs to detect at runtime which one to use. Well, the second one could
be "empty", since it uses system libs instead of driver dependent ones.
How ever this runtime detection could look like.


Andreas

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

[Luca Boccassi]

On Thu, 2017-10-05 at 18:24 +0100, Luca Boccassi wrote:
> On Thu, 2017-10-05 at 19:08 +0200, Gunman wrote:
> > On 04.10.2017 00:22, Luca Boccassi wrote:
> > > 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.
> > 
> > Would probably be interesting to install Stretch and then update to
> > SID.
> > 
> > > 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
> > 
> > That works too, with the __GLVND_DISALLOW_PATCHING=1. Without it,
> > it 
> > still gives a black screen/window.
> 
> Great, thanks for confirming.
> 
> > > It would be tricky to ship it in the packages, as without the
> > > glvnd
> > > it
> > > would actually break it.
> > 
> > Would it be easier/cleaner to create a second package? primus-glvnd
> > for 
> > example? So for the legacy drivers one still could use primus and
> > for 
> > the mesa-glvnd one would have to use primus-glvnd.
> 
> The problem is that the config file belongs to bumblebee rather than
> primus. Also optirun -b primus will have the same problem. It also
> makes installing the whole stack more complicated - right now one can
> apt install bumblebee-nvidia and everything will be there.
> 
> > > 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?
> > 
> > For me that package is not installed and pretty much uninstallable 
> > anyway. Or did you mean libgl1-nvida-glvnd-glx?
> 
> Yes sorry, that one.

I've uploaded to Sid a change that adds this Breaks. I did a few tests
with upgrades and clean installs with apt and aptitude and it looked
like it was fine.
Please let me know if there are any issues.

Andreas,

Long term, the only easy to maintain solution I can see (until there is
proper support upstream for GLVND) would be to change the config in a
postinst, depending on what package is installed. But that feels very
wrong (changing config files) and very fragile.
What do you think?

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

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

[Luca Boccassi]

On Thu, 2017-10-05 at 19:08 +0200, Gunman wrote:
> On 04.10.2017 00:22, Luca Boccassi wrote:
> > 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.
> 
> Would probably be interesting to install Stretch and then update to
> SID.
> 
> > 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
> 
> That works too, with the __GLVND_DISALLOW_PATCHING=1. Without it, it 
> still gives a black screen/window.

Great, thanks for confirming.

> > It would be tricky to ship it in the packages, as without the glvnd
> > it
> > would actually break it.
> 
> Would it be easier/cleaner to create a second package? primus-glvnd
> for 
> example? So for the legacy drivers one still could use primus and
> for 
> the mesa-glvnd one would have to use primus-glvnd.

The problem is that the config file belongs to bumblebee rather than
primus. Also optirun -b primus will have the same problem. It also
makes installing the whole stack more complicated - right now one can
apt install bumblebee-nvidia and everything will be there.

> > 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?
> 
> For me that package is not installed and pretty much uninstallable 
> anyway. Or did you mean libgl1-nvida-glvnd-glx?

Yes sorry, that one.

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

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

[Gunman]

On 04.10.2017 00:22, Luca Boccassi wrote:

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.

Would probably be interesting to install Stretch and then update to SID.


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
That works too, with the __GLVND_DISALLOW_PATCHING=1. Without it, it 
still gives a black screen/window.



It would be tricky to ship it in the packages, as without the glvnd it
would actually break it.
Would it be easier/cleaner to create a second package? primus-glvnd for 
example? So for the legacy drivers one still could use primus and for 
the mesa-glvnd one would have to use primus-glvnd.



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?
For me that package is not installed and pretty much uninstallable 
anyway. Or did you mean libgl1-nvida-glvnd-glx?


Best regards

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

signature.asc
Description: This is a digitally signed message part

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

[Bernd Vaske]

On Mon, 25 Sep 2017 20:50:53 +0200 Andreas Beckmann  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.

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

[Timo Aaltonen]

On 25.09.2017 21:50, Andreas Beckmann wrote:
> [ Cc:ing the libglvnd maintainer ]

The maintainer is debian-x, btw

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

You mean the legacy drivers don't support it? That's wonderful..


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


-- 
t

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

[Andreas Beckmann]

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

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

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

[Emilio J . Padrón]

Package: primus
Version: 0~20150328-4
Followup-For: Bug #876033

Dear Maintainer,

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

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? :-?


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages primus depends on:
ii  bumblebee 3.2.1-16
ii  primus-libs   0~20150328-4
ii  socat 1.7.3.2-1
ii  xserver-xorg-core 2:1.19.3-2
ii  xserver-xorg-video-intel  2:2.99.917+git20161206-1

Versions of packages primus recommends:
pn  primus-libs-ia32  

primus suggests no packages.

% dpkg -l | grep -E 'libe?gl'   

   
ii  libegl-mesa0:amd64 17.2.1-1
ii  libegl-nvidia0:amd64   375.82-4
ii  libegl-nvidia0:i386375.82-4
ii  libegl1:amd64  0.2.999+git20170802-4
ii  libegl1:i386   0.2.999+git20170802-4
ii  libegl1-mesa:amd64 17.2.1-1
ii  libegl1-mesa-dev:amd64 17.2.1-1
ii  libgl1:amd64   0.2.999+git20170802-4
ii  libgl1:i3860.2.999+git20170802-4
ii  libgl1-mesa-dev:amd64  17.2.1-1
ii  libgl1-mesa-dri:amd64  17.2.1-1
ii  libgl1-mesa-glx:amd64  17.2.1-1
ii  libgl1-nvidia-glvnd-glx:amd64  375.82-4
ii  libgl1-nvidia-glvnd-glx:i386   375.82-4
ii  libglapi-mesa:amd6417.2.1-1
ii  libgles-nvidia1:amd64  375.82-4
ii  libgles-nvidia1:i386   375.82-4
ii  libgles-nvidia2:amd64  375.82-4
ii  libgles-nvidia2:i386   375.82-4
ii  libgles1-glvnd-nvidia:amd64375.82-4
ii  libgles1-glvnd-nvidia:i386 375.82-4
ii  libgles2:amd64 0.2.999+git20170802-4
ii  libgles2:i386  0.2.999+git20170802-4
ii  libglew-dev:amd64  2.0.0-5
ii  libglew2.0:amd64   2.0.0-5
ii  libglib2.0-0:amd64 2.54.0-1
ii  libglib2.0-bin 2.54.0-1
ii  libglib2.0-data2.54.0-1
ii  libglib2.0-dev:amd64   2.54.0-1
ii  libglib2.0-dev-bin 2.54.0-1
ii  libglibmm-2.4-1v5:amd642.54.1-1
ii  libgltf-0.1-1:amd640.1.0-2
ii  libglu1-mesa:amd64 9.0.0-2.1
ii  libglu1-mesa-dev:amd64 9.0.0-2.1
ii  libglvnd-core-dev  0.2.999+git20170802-4
ii  libglvnd-dev   0.2.999+git20170802-4
ii  libglvnd0:amd640.2.999+git20170802-4
ii  libglvnd0:i386 0.2.999+git20170802-4
ii  libglx-mesa0:amd64 17.2.1-1
ii  libglx-nvidia0:amd64   375.82-4
ii  libglx-nvidia0:i386375.82-4
ii  libglx0:amd64  0.2.999+git20170802-4
ii  libglx0:i386   0.2.999+git20170802-4

-- no debconf information

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

[Luigi Curzi]

Hi,

On Wed, 20 Sep 2017 11:40:29 +0100 Luca Boccassi  wrote:
> On Sun, 2017-09-17 at 18:17 +0200, Luigi wrote:
> > Package: primus
> > Version: 0~20150328-4
> > Severity: grave
> > Justification: renders package unusable
> >
> > i installed primus, bumblebee and bumblebee-nvidia; i launched
> > primusrun but i obtained this output:
> > $ primusrun glxgears -info
> > /usr/bin/primusrun: riga 41: attenzione: 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
> >
> > In my system libGL.so.1 is located in these directories:
> > ~$ locate libGL.so.1
> > /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu
> > /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
> > /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.0.0
> > /usr/lib/x86_64-linux-gnu/libGL.so.1
> > /usr/lib/x86_64-linux-gnu/primus/libGL.so.1
> >
> >
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable
> >   APT policy: (990, 'unstable'), (50, 'experimental')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
> > LANGUAGE= (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages primus depends on:
> > ii  bumblebee  3.2.1-16
> > ii  primus-libs0~20150328-4
> > ii  socat  1.7.3.2-1
> > ii  xserver-xorg-core  2:1.19.3-2
> >
> > Versions of packages primus recommends:
> > pn  primus-libs-ia32  
> >
> > primus suggests no packages.
> >
> > -- no debconf information
>
> Hi,
>
> Could you please try again with nvidia-driver 375.82-4 that was just
> uploaded to unstable? There are some fixes w.r.t. compatibility with
> mesa+glvnd

i tried, but it didn't work; i got same error.

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

[Luigi Curzi]

On Wed, 20 Sep 2017 01:10:56 +0200 Bernd Vaske  wrote:
Hello,

> the problem comes from the transition of mesa to glvnd.
> A workaround is to link the missing libs from
>
> /usr/lib/x86_64-linux-gnu/libGL.so.1 to
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
> and
> /usr/lib/i386-linux-gnu/libGL.so.1 to
> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1
>
> That will result in primusrun starting again but most likely resulting
> in a black window for the application which is started.
>
> To get primusrun to work properly you have to start it with
> __GLVND_DISALLOW_PATCHING=1
>
> example:
>
> __GLVND_DISALLOW_PATCHING=1 primusrun glxgears
>

this solution works.
Thank you.

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

[Luca Boccassi]

On Sun, 2017-09-17 at 18:17 +0200, Luigi wrote:
> Package: primus
> Version: 0~20150328-4
> Severity: grave
> Justification: renders package unusable
> 
> i installed primus, bumblebee and bumblebee-nvidia; i launched
> primusrun but i obtained this output:
> $ primusrun glxgears -info
> /usr/bin/primusrun: riga 41: attenzione: 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
> 
> In my system libGL.so.1 is located in these directories:
> ~$ locate libGL.so.1
> /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.0.0
> /usr/lib/x86_64-linux-gnu/libGL.so.1
> /usr/lib/x86_64-linux-gnu/primus/libGL.so.1 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (50, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
> LANGUAGE= (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages primus depends on:
> ii  bumblebee  3.2.1-16
> ii  primus-libs0~20150328-4
> ii  socat  1.7.3.2-1
> ii  xserver-xorg-core  2:1.19.3-2
> 
> Versions of packages primus recommends:
> pn  primus-libs-ia32  
> 
> primus suggests no packages.
> 
> -- no debconf information

Hi,

Could you please try again with nvidia-driver 375.82-4 that was just
uploaded to unstable? There are some fixes w.r.t. compatibility with
mesa+glvnd

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

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

[Bernd Vaske]

Hello,

the problem comes from the transition of mesa to glvnd.
A workaround is to link the missing libs from

/usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1

and
/usr/lib/i386-linux-gnu/libGL.so.1 to 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1


That will result in primusrun starting again but most likely resulting 
in a black window for the application which is started.


To get primusrun to work properly you have to start it with 
__GLVND_DISALLOW_PATCHING=1


example:

__GLVND_DISALLOW_PATCHING=1 primusrun glxgears

Best regards

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

[Luca Boccassi]

Control: tags -1 moreinfo

On Sun, 2017-09-17 at 18:17 +0200, Luigi wrote:
> Package: primus
> Version: 0~20150328-4
> Severity: grave
> Justification: renders package unusable
> 
> i installed primus, bumblebee and bumblebee-nvidia; i launched
> primusrun but i obtained this output:
> $ primusrun glxgears -info
> /usr/bin/primusrun: riga 41: attenzione: 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
> 
> In my system libGL.so.1 is located in these directories:
> ~$ locate libGL.so.1
> /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.0.0
> /usr/lib/x86_64-linux-gnu/libGL.so.1
> /usr/lib/x86_64-linux-gnu/primus/libGL.so.1 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (50, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
> LANGUAGE= (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages primus depends on:
> ii  bumblebee  3.2.1-16
> ii  primus-libs0~20150328-4
> ii  socat  1.7.3.2-1
> ii  xserver-xorg-core  2:1.19.3-2
> 
> Versions of packages primus recommends:
> pn  primus-libs-ia32  
> 
> primus suggests no packages.
> 
> -- no debconf information

Hi,

Please attach the status of the nvidia stack on your system.

You can do that with reportbug:

reportbug -N 876033 nvidia-driver

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

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

[Luigi]

Package: primus
Version: 0~20150328-4
Severity: grave
Justification: renders package unusable

i installed primus, bumblebee and bumblebee-nvidia; i launched primusrun but i 
obtained this output:
$ primusrun glxgears -info
/usr/bin/primusrun: riga 41: attenzione: 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

In my system libGL.so.1 is located in these directories:
~$ locate libGL.so.1
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.0.0
/usr/lib/x86_64-linux-gnu/libGL.so.1
/usr/lib/x86_64-linux-gnu/primus/libGL.so.1 


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages primus depends on:
ii  bumblebee  3.2.1-16
ii  primus-libs0~20150328-4
ii  socat  1.7.3.2-1
ii  xserver-xorg-core  2:1.19.3-2

Versions of packages primus recommends:
pn  primus-libs-ia32  

primus suggests no packages.

-- no debconf information