Please set the LD_LIBRARY_PATH as follows and check.
Note: You may check section 3 APP SDK on Linux-> 3.3 OpenCL-> 3.3.1 Prerequisites in APP APP SDK 3.0 beta Getting Started Guide (
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_APP_SDK_Getting_Started_Guide1.pdf). I guess this may be same here.
Thank you for the reply. Unfortunately it doesn't work. I did play around with ld.so.conf.d/ and LD_LIBRARY_PATH before asking for help. No path can help, if the library doesn't exist in my system :-(
The only swrast_dri.so that I have is under /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so, and that is not even the right one, since I tried it and gives unresolved symbols. Note that i don't have SDK 3.0 only 2.9-1.
My question is: libGL used by spectrum is the one supplied by the omega catalyst, and is asking for swrast_dri.so under fglrx. Shouldn't this be supplied by the omega catalyst as well? Does the catalyst driver have it?
Tardis:~-> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/fglrx
Tardis:~-> echo $LD_LIBRARY_PATH
Tardis:~-> ls -la /usr/lib/fglrx
drwxr-xr-x 4 root root 4096 Dec 13 13:42 .
drwxr-xr-x 172 root root 28672 Dec 12 00:17 ..
-rw-r--r-- 1 root root 440 Dec 12 00:06 10fglrx
-rw-r--r-- 1 root root 1 Dec 12 00:06 alt_ld.so.conf
drwxr-xr-x 3 root root 4096 Dec 10 22:40 etc
-rw-r--r-- 1 root root 32 Dec 13 13:42 ld.so.conf
lrwxrwxrwx 1 root root 12 Dec 12 00:06 libGL.so.1 -> libGL.so.1.2
-rw-r--r-- 1 root root 868160 Dec 12 00:07 libGL.so.1.2
-rwxr-xr-x 1 root root 10272 Dec 12 00:06 switchlibGL
-rwxr-xr-x 1 root root 10276 Dec 12 00:06 switchlibglx
drwxr-xr-x 3 root root 4096 Dec 11 23:49 xorg
Tardis:~-> cd hydra/spectrum
Tardis:~/work/hydra/spectrum-> spectrum rb
[+] Selected device: Pitcairn
libGL error: dlopen /usr/lib/fglrx/dri/swrast_dri.so failed (/usr/lib/fglrx/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL error: dlopen /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so failed (/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL error: dlopen /usr/lib32/fglrx/dri/swrast_dri.so failed (/usr/lib32/fglrx/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL error: dlopen /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 157 (GLX)
Minor opcode of failed request: 5 (X_GLXMakeCurrent)
Serial number of failed request: 36
Current serial number in output stream: 36
Can anyone with Linux and omega catalyst tell me if there is a /usr/lib/fglrx/dri/swrast_dri.so file in their system?
Turns out this is a mesa problem since mesa-10.1.1. Now at mesa 10.1.3 still have unresolved symbols 14.04 Ubuntu, and a host of other Linux, have broken swrast implementations.
/usr/lib/fglrx/10fglrx, used in Xsession initialization sets LIBGL_DRIVERS_PATH=/usr/lib/fglrx/dri:...and points to the wrong direction.
Catalyst is innocent. Now, I have to find a way to fix my ubuntu box...
there is only /usr/lib/dri/fglrx_dri.so now and there is no /usr/lib/fglrx/dri
Finally, smt that makes sense. ty so much. Indeed all this time I have been using my system's libGL, with a broken swrast_dri.so. The LD_LIBRARY_PATH suggested by dipak, doesn't work. I still have to untangle the different libraries in my system. However, the one time I renamed my system's libGL.so, so that only the fglrx/libGL.so existed, it worked both for my ocl application and glxinfo ;-)
In fact ldd will show the correct library for my app:
libGL.so.1 => /usr/lib/fglrx/libGL.so.1 (0x00007f2284dc8000)
But at runtime it will use the system's libGL. Go figure :-(
1 of 1 people found this helpful
I tryed this code
void *gl1 = dlopen("libGL.so.1", RTLD_LAZY); void *gl2 = dlopen("libGL.so", RTLD_LAZY); dl_iterate_phdr(callback, NULL);
Callback function print name of the loaded library. It print that both /usr/lib/fglrx/libGL.so.1 and /usr/lib/x86_64-linux-gnu/libGL.so are loaded. Also handle values in gl1 and gl2 are different. If I switch order which the libGL.so are loaded then only /usr/lib/x86_64-linux-gnu/libGL.so is loaded and handle values are same. In other word if you load libGL.so first then you get only mesa libGL.so
Yes. That is because there is no /usr/lib/fglrx/libGL.so, so if you try to load this first, you will get the mesa libGL. After system loads it, it caches all relevant info and sees that there is a libGL.so.1 link to mesa, so it uses the cached copy for it. If you try to load libGL.so.1 first, you force it to search for it and depending on your path priorities, it will get the fglrx one. Next call will get again the mesa one.
However, this is runtime linking, that doesn't show in ldd. My app links libGL at compile time, so this is an issue with the linker, ld. Now my app runs fine. I have disabled the system's libGL, since it is buggy anyway, and use the flgrx one for both my system and ocl. Filed also a ticket with Ubuntu about it ;-)