Re: shared library problem
On Fri, Feb 05, 1999 at 04:31:50PM +0100, Wichert Akkerman wrote:
>
> I've encountered a slight problem while working on dpkg-db that I don't
> know how to fix. Here is the situation: I have an executable that loads
> a library, which uses libgdbm. Here is how I compile it:
>
> [thunder;~/cm]-18> make
> gcc -Wall -g -shared -o module.so module.c -lc -lgdbm
> chmod a-x module.so
> gcc -Wall -g -o main main.c -ldl
>
> Now when I run this things go wrong:
>
> [thunder;~/cm]-19> ./main
> Initializing
> Segmentation fault (core dumped)
> Exit 139
>
> What happens is that main calls a function in the module which prints the
> text "Initializing", which works. Then it calls another function that uses
> something from libgdbm. And then the shit hits the fan..
It shouldn't--your module should attempt to load libgdbm when it is
dlopen()'ed, if it's linked with it. So, two useful data points would be
the output of ldd modules.so, and strace ./main. If ldd modules.so shows
libgdbm, then strace should show evidence that the linker is trying to load
it (and hopefully point out why it fails).
I do reproduce the seg fault when the second library (in your case, libgdbm)
can't be found, or when the first library is in fact not linked with the
second. (In one case--when the first library is not linked with the second,
and main dlopen's the first library with RTLD_LAZY, I get an "error in
loading shared libraries ... undefined symbol". Strangely, I get the core
dump with the other three combinations.) However, when the first library is
correctly linked and the second is in the lib path, things work perfectly.
(The lack of a graceful failure by the linker is an annoying bug. Any
binutils hackers listening?)
Anyway, if this doesn't help, I'll be happy to compare a sample of your code
with my experiments (which I did on an x86 slink system).
Andrew
--
"It's like a love-hate relationship, without the love"
- Jamie Zawinski, consummate UNIX hater, on Linux
Reply to: