Hi. I'm running the 20080103 release of BuGLe, and I can't get gldb-gui or gldb to link in libbugle.so. I get this message:
ERROR: ld.so: object 'libbugle.so' from LD_PRELOAD cannot be preloaded: ignored.
I've tried both a local installation within my non-root account and I tried a system-wide installation using the default paths. I get the same message with both setups. I've tried specifying "LD_PRELOAD=/absolute/path/to/libbugle.so" before the executable name with no further success. I've tried specifying the lib's folder in /etc/ld.so.conf. If I don't use gldb or gldb-gui, I seem to be able to link just fine with LD_PRELOAD to run some filters.
All this is on Fedora 8. If I can provide any more info to help figure this problem out, please let me know. Thanks!
I'm not sure what the problem is, perhaps you can give me some more information:
1. Exactly what command are you running that gives the error?
2. Is it occurring when you run the command to start gldb[-gui], or when you select Run within the debugger?
3. Are you running a 64-bit system, and if so, is there any kind of mix of 32- and 64- bit things?
4. When doing things without gldb-gui (where you say it works), do you have to pass the full path or the does just LD_PRELOAD=libbugle.so with no path work?
gldb-gui appears to be working now, and I can't explain the change, apart from a reboot and an updated NVIDIA driver. Sorry. The command I was running was "gldb-gui anyopenglprogram". The linker message didn't appear until I selected Run. I'm only on 32-bit. And currently I do not need to pass the full path when defining LD_PRELOAD. When I had user-level install, I did need to specify the full path.
Thanks for your response! If I can recreate the error, I'll post more info.
I think gldb-gui launches the command by setting LD_PRELOAD to just libbugle.so. So if your system setup doesn't have libbugle.so in a default path then that would probably cause the error. I'll make a mental note to document this in the next release.
Well, I've removed the system-wide install and have only a user-level install now (using --prefix=$(HOME)/blah), and it's still working fine. In a previous version, gldb-gui ran just fine without having to twiddle with /etc/ld.so.conf for a user-level install. I don't know how it found it, for I see it set in gldb/gldb-common.c as you say.
I realize now that the cause of my problem was not running the ldconfig utility after setting the path in /etc/ld.so.conf. I didn't realize ld used a cache to locate shared libraries, which explains why a reboot made a user-level install start working suddenly.
Log in to post a comment.