cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

ekondis
Adept II

Execution issues of CodeXL 1.6 on 64bit Linux

The CodeXL analyser has a problem when is executed either as standalone or through CodeXL GUI. It seems it tries to load the 32bit GL library. For instance using it to get a list of supporting GPUs I get the following output:

$ ./CodeXLAnalyzer -h -s CL -l

Assertion failure (Failed to load module. OS error is: /usr/lib32/fglrx/dri/../libGL.so.1: wrong ELF class: ELFCLASS32. Module = l) osLoadModule /data/jenkins/workspace/CodeXL-1.6-Linux/release/CodeXL/1.6/CommonProjects/AMDTOSWrappers/src/linux/osModule.cpp line: 62

: No such file or directory

AMD Catalyst was not detected.

Devices:

The same happens if I open the CodeXL GUI.

However, if I change the link /usr/lib32/fglrx/libGL.so.1 to point to the 64bit libGL.so (/usr/lib/fglrx/libGL.so) then both the analyser and CodeXL run without a problem.

How can I correct this in a proper way?

0 Likes
1 Solution
dorono
Staff

Hi ekondis,

This is a known issue with CodeXL 1.6. Your workaround is valid. This should be fixed in the next release.

View solution in original post

0 Likes
5 Replies
dorono
Staff

Hi ekondis,

This is a known issue with CodeXL 1.6. Your workaround is valid. This should be fixed in the next release.

0 Likes

On a different system the libGL.so.1 is seeked on a different path as the following output shows. Is there any way to control it?


Assertion failure (Failed to load module. OS error is: /usr/lib/libGL.so.1: cannot open shared object file: No such file or directory. Module = l) osLoadModule /data/jenkins/workspace/CodeXL-1.6-Linux/release/CodeXL/1.6/CommonProjects/AMDTOSWrappers/src/linux/osModule.cpp line: 62


: No such file or directory


AMD Catalyst was not detected.


Devices:


0 Likes

With respect to your original question, CodeXL 1.6 seeks the path dri/libGL.so.1 in x64 systems. I think a better workaround in terms of architecture, is to create /usr/lib/fglrx/dri and link there the /usr/lib/fglrx/libGL.so.1 library. Doesn't mix x32 with x64 arch, so if you try ever to run a x32 app, you can still get the right libs. Try this on your 2nd system as well. If it doesn't work you might need to link /usr/lib/fglrx/libGL.so.1 under /usr/lib. I know, this gets the fs dirty, but just until the update is due. Same problem exists also with CodeXL 1.5 😞

Confirming the symbolic link worked for me.

The exact commands needed were:

mkdir /usr/lib/fglrx/dri
ln -s /usr/lib/fglrx/libGL.so.1 /usr/lib/fglrx/dri/libGL.so.1

I'm seeing this persist in 1.7, however I am using a config from a previous version so perhaps it is spilling over that way.

0 Likes