/usr/lib/libGL.so: wrong ELF class: ELFCLASS3

Help
2008-02-28
2013-06-13
  • Randall Hopper
    Randall Hopper
    2008-02-28

    The forum truncated the Subject, but that should be ELFCLASS32.

    I just built bugle-0.0.20080215 on Linux 64-bit for 64-bit, and I'm getting this error when I try to "Run" glxgears under gldb-gui.  I don't understand why bugle is even looking in /usr/lib.  I made the libtool tweak suggested in the FAQ (didn't work), and then further changed all /lib refs to /lib64 in libtool (still didn't work).  See below for some useful probing.

    Any ideas?  Why is bugle looking in /usr/lib.  Would really like to try bugle.

    BTW, is there a mailing list form of this forum?

    > gldb-gui glxgears
    /usr/lib/libGL.so: wrong ELF class: ELFCLASS32
    > which gldb-gui
    /opt/pkg/bugle/bin/gldb-gui
    > file /opt/pkg/bugle/bin/gldb-gui
    /opt/pkg/bugle/bin/gldb-gui: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped
    > file /opt/pkg/bugle/lib64/libbugle.so
    /opt/pkg/bugle/lib64/libbugle.so: symbolic link to `libbugle.so.5.1.1'
    > file /opt/pkg/bugle/lib64/libbugle.so.5.1.1
    /opt/pkg/bugle/lib64/libbugle.so.5.1.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), not stripped
    > ldd /opt/pkg/bugle/lib64/libbugle.so.5.1.1 | grep GL
            libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b038c64b000)
            libGLcore.so.1 => /usr/lib64/libGLcore.so.1 (0x00002b038d4bf000)
    > ldconfig -p | grep bugle.so
            libbugle.so.5 (libc6,x86-64) => /opt/pkg/bugle/lib64/libbugle.so.5
            libbugle.so (libc6,x86-64) => /opt/pkg/bugle/lib64/libbugle.so

    Thanks,

    Randall

     
    • Bruce Merry
      Bruce Merry
      2008-02-29

      I'm not sure what to suggest - libtool does strange things on its own that I don't really have control over, and it looks like you've already tried most of the things I would try. About all I can think to suggest is to run file and ldd on glxgears.

      By the way, what distribution are you running?

       
    • Randall Hopper
      Randall Hopper
      2008-02-29

      Thanks.  SuSE 10.3 64-bit.  Well, I'll try to pick through it next week when I have more time. 
      If you could point me to the right spot in the code or suggest some debug mods that'd be
      useful, I'd appreciate it.

      > file `which glxgears`
      /usr/bin/glxgears: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), stripped
      > ldd `which glxgears` | grep libGL
              libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b5fb81cf000)
              libGLcore.so.1 => /usr/lib64/libGLcore.so.1 (0x00002b5fb90a0000)
      > rpm -qv libtool
      libtool-1.5.24-17
      > rpm -qv glibc
      glibc-2.6.1-18.3
      > rpm -qv gcc
      gcc-4.2-24
      > uname -r
      2.6.22.17-0.1-default

       
    • Bruce Merry
      Bruce Merry
      2008-02-29

      You can start by trying to hardcode a path into the LIBRARY line at the start of gl.bc.in, or messing with the code in budgie_function_address_initialise (in budgielib/addresses.c) - at least putting some breakpoints or debug code in there should tell you if it is that code that is generating the error message.

      I might have this in the FAQ already, but check if there is a libGL.la anywhere - if there is the ltdl tends to read that, and it might specify a path of /usr/lib.

      Regards
      Bruce

       
    • Thanks.  SuSE 10.3 64-bit.  Well, I'll try to pick through it next week when I have more time. 
      If you could point me to the right spot in the code or suggest some debug mods that'd be
      useful, I'd appreciate it.

      > file `which glxgears`
      /usr/bin/glxgears: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), stripped
      > ldd `which glxgears` | grep libGL
              libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b5fb81cf000)
              libGLcore.so.1 => /usr/lib64/libGLcore.so.1 (0x00002b5fb90a0000)
      > rpm -qv libtool
      libtool-1.5.24-17
      > rpm -qv glibc
      glibc-2.6.1-18.3
      > rpm -qv gcc
      gcc-4.2-24
      > uname -r
      2.6.22.17-0.1-default

       
    • Bruce Merry
      Bruce Merry
      2008-02-29

      You can try hardcoding a path into the LIBRARY line in gl.bc.in. If that doesn't help, try putting breakpoints or printf's in budgie_function_address_initialise in budgielib/addresses.c to see whether the failure is in that code (I'm guessing it is).

      Also check whether there are any libGL.la files lying around. They might be causing ltdl to do weird things, like referencing /usr/lib. I've also found this in the libtool docs:

           If libltdl cannot find the library and the file name FILENAME does
           not have a directory component it will additionally search in the
           following search paths for the module (in the order as follows):

             1. user-defined search path: This search path can be changed by
                the program using the functions `lt_dlsetsearchpath',
                `lt_dladdsearchdir' and `lt_dlinsertsearchdir'.

             2. libltdl's search path: This search path is the value of the
                environment variable LTDL_LIBRARY_PATH.

             3. system library search path: The system dependent library
                search path (e.g. on Linux it is LD_LIBRARY_PATH).

           Each search path must be a colon-separated list of absolute
           directories, for example, `"/usr/lib/mypkg:/lib/foo"'.

      So, maybe try setting LTDL_LIBRARY_PATH to /usr/lib64.

      Let me know if any of this works, so I can add it to the FAQ.

       
      • Randall Hopper
        Randall Hopper
        2008-02-29

        Thanks.  Will give it a shot.

         
    • I had the same problem.
      Setting the  LTDL_LIBRARY_PATH  to /usr/lib64 helped for me.

      Greets Klaus