We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
I get the following assert when running the included 'cube' demo:
$ ./cube
GL renderer: [NULL]
GL vendor:[NULL]
GL version: [NULL]
GL shading language version: [NULL]
cube: /home/jenkins/workspace/opengles30-emulator-packaging-nightly/Arch/x64/OS/linux/gles/opengles30/src/gles30_system_fbo.cc:501: bool system_fbo_init(GLuint, _context_data*, bool): Assertion `depth_to_id != 0' failed.
Aborted (core dumped)
The backtrace is as follows:
#0 0x00007ffff67bcf77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff67c05e8 in __GI_abort () at abort.c:90
#2 0x00007ffff67b5d43 in __assert_fail_base (fmt=0x7ffff690cf58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ffff7873c9d "depth_to_id != 0",
file=file@entry=0x7ffff7873b80 "/home/jenkins/workspace/opengles30-emulator-packaging-nightly/Arch/x64/OS/linux/gles/opengles30/src/gles30_system_fbo.cc",
line=line@entry=501,
function=function@entry=0x7ffff7873ce0 <system_fbo_init(unsigned int, _context_data*, bool)::__PRETTY_FUNCTION__> "bool system_fbo_init(GLuint, _context_data*, bool)")
at assert.c:92
#3 0x00007ffff67b5df2 in __GI___assert_fail (assertion=0x7ffff7873c9d "depth_to_id != 0",
file=0x7ffff7873b80 "/home/jenkins/workspace/opengles30-emulator-packaging-nightly/Arch/x64/OS/linux/gles/opengles30/src/gles30_system_fbo.cc", line=501,
function=0x7ffff7873ce0 <system_fbo_init(unsigned int, _context_data*, bool)::__PRETTY_FUNCTION__> "bool system_fbo_init(GLuint, _context_data*, bool)") at assert.c:101
#4 0x00007ffff777319a in system_fbo_init(unsigned int, _context_data*, bool) () from /usr/local/lib/libGLESv2.so.2
#5 0x00007ffff777892d in init_context_data_from_within_active_context(unsigned int, _context_data*) () from /usr/local/lib/libGLESv2.so.2
#6 0x00007ffff77a6e0b in context_data_storage_make_context_current () from /usr/local/lib/libGLESv2.so.2
#7 0x00007ffff77a3c02 in GLES3_MakeCurrent () from /usr/local/lib/libGLESv2.so.2
#8 0x00007ffff77a3c7d in GLES2_MakeCurrent () from /usr/local/lib/libGLESv2.so.2
#9 0x00007ffff7ba71bf in GLES2_MakeCurrent () from /usr/local/lib/libEGL.so.1
#10 0x00007ffff7ba9e23 in makeCurrent(void*, void*, void*, void*) () from /usr/local/lib/libEGL.so.1
#11 0x00007ffff7bae4af in eglMakeCurrent () from /usr/local/lib/libEGL.so.1
#12 0x000000000040223e in main (argc=1, argv=0x7fffffffdd38) at src/cube.cc:283
When using the libEGL.so.1 and libGLESv2.so.1 bundled with Mesa (LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/mesa-egl/ ./cube on my system) instead of those from the emulator, the example runs fine.
System specs:
uname -a: Linux huvuddator 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 13.10
GeForce GT 430, NVIDIA driver version 319.32
The same problem also occurs on a different system with the following specs (where it also runs fine with the Mesa libs):
uname -a: Linux jp 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
GeForce GTX 660 Ti, NVIDIA driver version 304.108
That fixed it - thanks!
It seems a bit strange though, since the NVIDIA driver is apparently already in the dynamic linker's search path:
$ ldd cube
linux-vdso.so.1 => (0x00007fffebbfe000)
libEGL.so.1 => /usr/local/lib/libEGL.so.1 (0x00007fb7fce6c000)
libGLESv2.so.2 => /usr/local/lib/libGLESv2.so.2 (0x00007fb7fc99c000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fb7fc666000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb7fc362000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb7fc05e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb7fbe47000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb7fba7f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb7fb87b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb7fb65d000)
libGL.so.1 => /usr/lib/nvidia-319/libGL.so.1 (0x00007fb7fb32f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb7fd0f7000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fb7fb111000)
libnvidia-tls.so.319.32 => /usr/lib/nvidia-319/tls/libnvidia-tls.so.319.32 (0x00007fb7faf0d000)
libnvidia-glcore.so.319.32 => /usr/lib/nvidia-319/libnvidia-glcore.so.319.32 (0x00007fb7f89b6000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fb7f87a3000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fb7f859f000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fb7f8399000)
Shouldn't the dlopen("libGL.so", ...) or similar that I assume is being done at runtime automatically use the same search path?
($ LD_LIBRARY_PATH=/usr/lib/nvidia-319 ldd cube has the same output as above by the way, though I realize it can still affect runtime stuff.)