cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

nibal
Challenger

Missing libraries from omega catalyst?

When I try to run an ocl-c file, I get:

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)

There is no dri subdir under fglrx. Calling libGL is libGL.so.1 => /usr/lib/fglrx/libGL.so.1. All of them under the fglrx driver.

Does omega catalyst misses dri subdir, or do I have a broken installation? Attempting to fill it in from  /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so

results in unresolved symbols.

I haveUbuntu 14.04, latest omega catalyst driver and 2.9-1 SDK

0 Likes
1 Solution

there is only /usr/lib/dri/fglrx_dri.so now and there is no /usr/lib/fglrx/dri

View solution in original post

0 Likes
8 Replies
dipak
Big Boss

Hi,

Please set the LD_LIBRARY_PATH as follows and check.

Export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/fglrx


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.pd...). I guess this may be same here.


Regards,

0 Likes

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

/opt/AMDAPPSDK-2.9-1/lib/x86_64/:/usr/lib32:/usr/lib/fglrx

Tardis:~-> ls -la /usr/lib/fglrx

total 924

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

/home/nikos/work/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

0 Likes

Can anyone with Linux and omega catalyst tell me if there is a /usr/lib/fglrx/dri/swrast_dri.so file in their system?

TIA,

Nikos

0 Likes

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...

0 Likes

there is only /usr/lib/dri/fglrx_dri.so now and there is no /usr/lib/fglrx/dri

0 Likes

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 😞

0 Likes

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 😉

0 Likes