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
> 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
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?
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
> rpm -qv glibc
> rpm -qv gcc
> uname -r
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.
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.
Thanks. Will give it a shot.
I had the same problem.
Setting the LTDL_LIBRARY_PATH to /usr/lib64 helped for me.
Log in to post a comment.