nividia libGL.so lookup problem

[hjanetzek]

On Ubuntu 14.04 glfw seems to use /usr/lib/x86_64-linux-gnu/libGL.so -> mesa/libGL.so instead of /usr/lib/nvidia-304/libGL.so.304.117. According to

#ldconfig --verbose  | grep libGL.so
    libGL.so.1 -> libGL.so.304.117

the nvidia library should be used by default, I guess. Running a jglfw application with LD_LIBRARY_PATH=/usr/lib/nvidia-304/ works on the other hand. Any idea what might cause this problem?

LIBGL_DEBUG=verbose ../gradlew run
...
:vtm-desktop:run
libGL: screen 0 does not appear to be DRI3 capable
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
libGL: driver does not expose __driDriverGetExtensions_swrast(): /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: undefined symbol: __driDriverGetExtensions_swrast
libGL: Can't open configuration file /home/jeff/.drirc: No such file or directory.
libGL: Can't open configuration file /home/jeff/.drirc: No such file or directory.
libGL error: failed to load driver: swrast
X Error of failed request:  255
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  17 (X_GLXVendorPrivateWithReply)
  Serial number of failed request:  79
  Current serial number in output stream:  82

[badlogic]

Tough one, o idea i'm afraid :/

Maybe the GLFW guys have an idea?
On Jul 18, 2014 4:48 PM, "Hannes Janetzek" notifications@github.com wrote:

On Ubuntu 14.04 glfw seems to use /usr/lib/x86_64-linux-gnu/libGL.so ->
mesa/libGL.so instead of /usr/lib/nvidia-304/libGL.so.304.117. According to

#ldconfig --verbose | grep libGL.so
libGL.so.1 -> libGL.so.304.117

the nvidia library should be used by default, I guess. Running a jglfw
application with LD_LIBRARY_PATH=/usr/lib/nvidia-304/ works on the other
hand. Any idea what might cause this problem?

LIBGL_DEBUG=verbose ../gradlew run
...
:vtm-desktop:run
libGL: screen 0 does not appear to be DRI3 capable
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
libGL: driver does not expose __driDriverGetExtensions_swrast(): /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: undefined symbol: __driDriverGetExtensions_swrast
libGL: Can't open configuration file /home/jeff/.drirc: No such file or directory.
libGL: Can't open configuration file /home/jeff/.drirc: No such file or directory.
libGL error: failed to load driver: swrast
X Error of failed request: 255
Major opcode of failed request: 155 (GLX)
Minor opcode of failed request: 17 (X_GLXVendorPrivateWithReply)
Serial number of failed request: 79
Current serial number in output stream: 82

—
Reply to this email directly or view it on GitHub
#2.

[hjanetzek]

Programs that directly use GLFW work correctly. I looked now into the strace output to see which files were actually tried to find a libGL.so. It seems as if Java is overriding the lookup paths..

open("/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/../lib/amd64/jli/libGL.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/../lib/amd64/libGL.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libGL.so", O_RDONLY|O_CLOEXEC) = 31

[hjanetzek]

When using lwjgl backend the output is slightly different - I mean the libGL.so.1 instead of libGL.so

open("/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/../lib/amd64/jli/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/../lib/amd64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/nvidia-304/libGL.so.1", O_RDONLY|O_CLOEXEC) = 48

[badlogic]

We probably link against something we shouldn't link against. Not sure what
we do wrong really :/
On Jul 18, 2014 5:46 PM, "Hannes Janetzek" notifications@github.com wrote:

When using lwjgl backend the output is slightly different - I mean the
libGL.so.1 instead of libGL.so

open("/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/../lib/amd64/jli/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/../lib/amd64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/nvidia-304/libGL.so.1", O_RDONLY|O_CLOEXEC) = 48

—
Reply to this email directly or view it on GitHub
#2 (comment).

[hjanetzek]

hmm, probably the applications I tried use a different method than _GLFW_HAS_DLOPEN. Flipping the order in glfw-3.0/src/glx_context.c makes it work for me:

char* libGL_names[ ] =
{
"libGL.so.1",
"libGL.so",
"/usr/lib/libGL.so.1",
"/usr/lib/libGL.so",
NULL
};

[badlogic]

Great observation. We could just fix it up in our GLFW fork (which we
should synch again some time...)
On Jul 18, 2014 6:31 PM, "Hannes Janetzek" notifications@github.com wrote:

hmm, probably the applications I tried use a different method than
_GLFW_HAS_DLOPEN. Flipping the order in glfw-3.0/src/glx_context.c makes it
work for me:

char* libGL_names[ ] =
{
"libGL.so.1",
"libGL.so",
"/usr/lib/libGL.so.1",
"/usr/lib/libGL.so",
NULL
};

—
Reply to this email directly or view it on GitHub
#2 (comment).

[hjanetzek]

yea, just found that this has already been fixed upstream.. :)
glfw/glfw#261