Strange problem with primus (Optimus with bumblebee)

[Fulgurance]

Hello, i have strange problem, when i would like to launch any application with primusrun, i have this error:

Code: Select all

fulgurance@msi-gs73vr-6rf ~ $ primusrun firefox
primus: fatal: failed to load any of the libraries: /usr/lib64/opengl/nvidia/lib/libGL.so.1:/usr/lib/opengl/nvidia/lib/libGL.so.1
libGLX.so.0: cannot open shared object file: No such file or directory
/usr/lib/opengl/nvidia/lib/libGL.so.1: cannot open shared object file: No such file or directory

fulgurance@msi-gs73vr-6rf ~ $ ls /usr/lib64/opengl/nvidia/lib
libEGL_nvidia.so         libGLdispatch.so               libGLESv1_CM.so.1           libGLESv2.so.2      libGLX_nvidia.so.0
libEGL_nvidia.so.0       libGLdispatch.so.0             libGLESv1_CM.so.1.2.0       libGLESv2.so.2.1.0  libGLX_nvidia.so.435.21
libEGL_nvidia.so.435.21  libGLESv1_CM_nvidia.so         libGLESv2_nvidia.so         libGL.so            libGLX.so
libEGL.so                libGLESv1_CM_nvidia.so.1       libGLESv2_nvidia.so.2       libGL.so.1          libGLX.so.0
libEGL.so.1              libGLESv1_CM_nvidia.so.435.21  libGLESv2_nvidia.so.435.21  libGL.so.1.7.0      libOpenGL.so
libEGL.so.435.21         libGLESv1_CM.so                libGLESv2.so                libGLX_nvidia.so    libOpenGL.so.0
fulgurance@msi-gs73vr-6rf ~ $ ls /usr/lib/opengl/nvidia/lib/
ls: impossible d'accéder à '/usr/lib/opengl/nvidia/lib/': Aucun fichier ou dossier de ce type

This file exist in lib64 dir, but no into lib dir

Is it possible this problem come with the new architecture of lib and lib64 directories ?

[Fulgurance]

Nobody have any idea?

[hhfeuer]

AFAIK, primus is broken with nvdia drivers >418 anyway since it needs the non-glvnd compat libs which don't exist anymore.

[azurecrimson]

I have a similar issue, try switching the OpenGL implementation (definitely an unacceptable workaround for me as it breaks some apps when run without primus).

Code: Select all

$ sudo eselect opengl set xorg-x11
Switching to xorg-x11 OpenGL interface... done
$ kitty
^C
$ primusrun kitty
primus: fatal: failed to load any of the libraries: /usr/lib64/opengl/nvidia/lib/libGL.so.1
libGLX.so.0: cannot open shared object file: No such file or directory
$ primusrun glxgears
primus: fatal: failed to load any of the libraries: /usr/lib64/opengl/nvidia/lib/libGL.so.1
libGLX.so.0: cannot open shared object file: No such file or directory

$ sudo eselect opengl set nvidia  
Switching to nvidia OpenGL interface... done
$ kitty
[292 11:39:49.845512] [glfw error 65542]: GLX: No GLXFBConfigs returned
[292 11:39:49.845561] [glfw error 65545]: GLX: Failed to find a suitable GLXFBConfig
[292 11:39:49.845590] Failed to create GLFW temp window! This usually happens because of old/broken OpenGL drivers. kitty requires working OpenGL 3.3 drivers.
$ primusrun kitty
^C
$ primusrun glxgears
303 frames in 5.0 seconds = 60.440 FPS

Now we just need to figure out how primusrun is supposed to choose a non-default OpenGL implementation on a normal system...

[azurecrimson]

Took some snapshots after running eselect and made a diff using btrfs-diff. I annotated it with a quick description of the diff:

Code: Select all

OPENGL_PROFILE='nvidia/xorg-x11':
  etc/csh.env
  etc/profile.env

OPENGL_PROFILE={'nvidia','xorg-x11'} and LDPATH={'/usr/lib/opengl/nvidia/lib:/usr/lib64/opengl/nvidia/lib',''}
  etc/env.d/000opengl

Nvidia version has "/usr/lib/opengl/nvidia/lib" and /usr/lib64/opengl/nvidia/lib"
  etc/ld.so.conf

Binary file, the xorg-x11 version is ~3kb smaller than the nvidia one
  etc/ld.so.cache

Identical contents (but mtime changed)
  etc/X11/xorg.conf.d/20opengl.conf
  var/cache/ldconfig/aux-cache

Simply setting LD_LIBRARY_PATH for primusrun works, but for convenience here's a wrapper (put it in /usr/local/bin or something early in your system $PATH).

Code: Select all

#!/bin/sh
export OPENGL_PROFILE=nvidia
export LD_LIBRARY_PATH=/usr/lib/opengl/nvidia/lib:/usr/lib64/opengl/nvidia/lib
/usr/bin/primusrun $@

[truekaiser]

Took some snapshots after running eselect and made a diff using btrfs-diff. I annotated it with a quick description of the diff:

Code: Select all

OPENGL_PROFILE='nvidia/xorg-x11':
  etc/csh.env
  etc/profile.env

OPENGL_PROFILE={'nvidia','xorg-x11'} and LDPATH={'/usr/lib/opengl/nvidia/lib:/usr/lib64/opengl/nvidia/lib',''}
  etc/env.d/000opengl

Nvidia version has "/usr/lib/opengl/nvidia/lib" and /usr/lib64/opengl/nvidia/lib"
  etc/ld.so.conf

Binary file, the xorg-x11 version is ~3kb smaller than the nvidia one
  etc/ld.so.cache

Identical contents (but mtime changed)
  etc/X11/xorg.conf.d/20opengl.conf
  var/cache/ldconfig/aux-cache

Simply setting LD_LIBRARY_PATH for primusrun works, but for convenience here's a wrapper (put it in /usr/local/bin or something early in your system $PATH).

Code: Select all

#!/bin/sh
export OPENGL_PROFILE=nvidia
export LD_LIBRARY_PATH=/usr/lib/opengl/nvidia/lib:/usr/lib64/opengl/nvidia/lib
/usr/bin/primusrun $@

Sorry to bring up an OLD post, but i recently ran into this, the suggestion on the wiki BORKS the entire system, and i want to know would just

Code: Select all

export LD_LIBRARY_PATH=/usr/lib/opengl/nvidia/lib:/usr/lib64/opengl/nvidia/lib

in the script alone with out the opengl profile?

[jmbreuer]

I ran into this playing Antichamber from Steam in primusrun.

On my system, there's a symbolic link

Code: Select all

/usr/lib64/opengl/nvidia/lib/libGL.so.1 -> ../../../libGL.so.1

I.e. it's pointing to /usr/lib64/libGL.so.1

That link probably came about using some manual fixing, I can't find a package it belongs to.

Antichamber wouldn't run since it is a 32 bit binary, and the corresponding link was missing for /usr/lib/opengl/nvidia/lib/libGL.so.1, so I created that one identically:

Code: Select all

/usr/lib/opengl/nvidia/lib/libGL.so.1 -> ../../../libGL.so.1

Antichamber at least is happy.

It'd be great to have those symlinks properly managed, but for now maybe this might help others running into the same problem.

[Hu]

That link probably came about using some manual fixing, I can't find a package it belongs to.

Historically, there were at least a few Gentoo tools that would set up links like this and not place them under a specific package, so the link may be the result of one of those tools (possibly even run automatically on your behalf by an ebuild) rather than manual modification that you have since forgotten.