jglfw
jglfw copied to clipboard
badlogic
nividia libGL.so lookup problem
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
Tough one, o idea i'm afraid :/
Maybe the GLFW guys have an idea? On Jul 18, 2014 4:48 PM, "Hannes Janetzek" [email protected] 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 https://github.com/badlogic/jglfw/issues/2.
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
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
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" [email protected] 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 https://github.com/badlogic/jglfw/issues/2#issuecomment-49446207.
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 };
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" [email protected] 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 https://github.com/badlogic/jglfw/issues/2#issuecomment-49451530.
yea, just found that this has already been fixed upstream.. :) https://github.com/glfw/glfw/issues/261