CODEWITHSUNDEEP
c++linuxqtlinkerintel
Sir Digby Chicken Caesar
Sir Digby Chicken Caesar

Reputation: 3123

Linking to 32bit shared object file in 32 bit enviornment generates ELFCLASS64 error

System : I'm running 32 bit Ubuntu 12.04 on a i32 chipset.

Build Info : I'm using C++ 11 with Qt 4.8.1 and GCC.

Problem : I am developing a project that depends on in-house developed libraries hereafter mentioned to as slug. These libraries are built into .so files via the traditional "cmake ." then "make all" process. After the .so files are generated from cmake, I copy the .so files into a sub-directory of my project so that I can test that they are working before I install them into /usr/lib. Then I provide Qt (in my .pro file) with a absolute path to each library and build my application. My application finds these local libraries and compiles without errors or warnings. However, when I run my application (via command line) I receive the following error:

    error while loading shared libraries: libslugSpec.so: wrong ELF class: ELFCLASS64

However, when I build the slug libraries on a 64 bit environment and link to them in a 64 bit environment my application runs perfectly. So, I figured I built the .so files for a 64 bit environment,and proceeded to edit the CMakeLists.txt file used to build the libraries. I add numerous 32 bit compilation and linking flags, shared object module flags, in addition to cuda (which slug relies on) bitness flags . No matter what combination of flags I tried, the libraries generated kept causing the error when running my application executable. So I decided to run the readelf -h command on each shared object file and check to see if they were really 64 bit. I found out that none of them are in fact, all producing logs similar to the following: (output for one of 3 .so files)

readelf -h libslugSpec.so 
ELF Header:
Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
Class:                             ELF32
Data:                              2's complement, little endian
Version:                           1 (current)
OS/ABI:                            UNIX - System V
ABI Version:                       0
Type:                              DYN (Shared object file)
Machine:                           Intel 80386
Version:                           0x1
Entry point address:               0x10150
Start of program headers:          52 (bytes into file)
Start of section headers:          511960 (bytes into file)
Flags:                             0x0
Size of this header:               52 (bytes)
Size of program headers:           32 (bytes)
Number of program headers:         7
Size of section headers:           40 (bytes)
Number of section headers:         38
Section header string table index: 35

So now I am completely at a loss and can't seem to find an answer anywhere. Any illumination into how this could be happening would be a huge help.

For reference, here are the flags I am providing in the qt .pro file that builds my application:

    QMAKE_CXXFLAGS += "-std=gnu++0x"

    QT  += core gui opengl
    TARGET = source
    TEMPLATE = app
    CONFIG+= wwwidgets


    #linux specific settings
    unix:!macx{
        LIBS +=  -lGLEW -lGLU  /home/alex/Dropbox/brain-viz/source/lib/libslugUtil.so /home/alex/Dropbox/brain-viz/source/lib/libslugSpec.so /home/alex/Dropbox/brain-viz/source/lib/libslugSim.so
    }

    #windows specific settings
    win32{
       LIBS += -lglew32 -lwwwidgets4d
    }

Upvotes: 1

Views: 413

Answers (1)

Employed Russian
Employed Russian

Reputation: 213526

This error message:

error while loading shared libraries: libslugSpec.so: wrong ELF class: ELFCLASS64

Is not consistent with this output:

readelf -h libslugSpec.so 
ELF Header:
Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
Class:                             ELF32

Conclusion: you load a different version of libslugSpec.so from the one you ran readelf -h on.

Find out which libslugSpec.so is loaded at runtime by doing this:

LD_DEBUG=files,libs /path/to/your/executable

Then run readelf -h on that library, and confirm that it is in fact ELF64.

Finally replace it with the version you've built (or set LD_LIBRARY_PATH to pick up your version before "system" one), and the problem will be solved.

Upvotes: 2

Related Questions