Date: Wed, 10 Apr 2002 19:52:24 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: bruno@tinkerbox.org Cc: hackers@freebsd.org Subject: Re: problems with shared libraries (fwd) Message-ID: <3CB4FA68.3C5540F8@mindspring.com> References: <Pine.BSF.4.21.0204101846480.68564-100000@mail.dvart.com>
next in thread | previous in thread | raw e-mail | index | archive | help
bruno@tinkerbox.org wrote:
> that worked, I dlopen'ed glib in my program and put a stub for the glib
> function that was failing. It was getting bad data. Guess glib needs some
> stuff inited first maybe... anyway, it seems it works by spoofing it !
>
> thanks
Glad it working... but what you did wasn't exactly what I had in
mind.
The problem comes from the linkage being ld argument order at
symbol resolution time, and hierarchically ordered at ld.so
load time.
It's very hard to draw a 3D diagram in 2D. So I'll ignore the
original link time issues, and show you what I meant and what
you did. What you did was:
prog {
f1 -> module.f1
f2 -> module.f2
libc {
}
module {
f1
f2
g1 -> glib.g1
glib {
g1
}
}
}
What I suggested was:
prog {
f1 -> wrapper.f1
f2 -> wrapper.f2
libc {
}
wrapper {
f1 -> module.f1
f2 -> module.f2
glib {
g1
}
module {
f1
f2
g1
}
}
}
The difference is that when the module goes to resolve symbols,
it looks for the symbols in its hierarchy. It's linked against
glib, but it's seeing the libc symbols, and so it's getting
confused. By explicitly putting the glib into the hierarchy
before the module is loaded, you ensure that it only gets libc
symbols if the glib symbols aren't there. In other words, the
glib symbols shadow the libc symbols.
The way you have it may work for your application, but it
general, can fail.
Another alternative is to explicitly link the module.so against
the glib.so. I have seen this fail for symbol sets 2 or more
deep (which is what I think was biting you) with things like
JNI implementations using shared objects for Kaffe.
Probably a better approach would be to register by name the
share modules, using a signle exported structure that contained
the name, and some generic entry points (e.g. "register yourself",
"deregister yourself", "user defined entry point", etc., via a
programmatic mux. Then you could also, as part of registration,
list your dependencies for particular modules, which would cause
them to be loaded.
You might also have worked around it with LD_PRELOAD; but doing
that, you would be likely to get glib components where the main
program was in fact expecting libc symbols to resolve.
The man page for "rtld" is quite informative, for debugging purposes...
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CB4FA68.3C5540F8>