Timshel Knoll <[EMAIL PROTECTED]> writes:
> Possible solutions:
4. Fix libtool and libltdl to support
lt_dlopen_interface (const char *name, int interface)
and use that.
This would require modifying libtool to install a versioned .la
files (on archs that can't just dlopen a .so file), and on at
least Linux, I believe it can just use the same algorithm that
ld.so does at runtime to find the "best" .so, i.e. the newest
.so* satisfying the requested interface. This would make normal
(ld.so) and runtime (dlopen) linking much more consistent IMO.
FWIW we're planning to do something like this in libltdl-guile
soon, and if we come up with something we think would be more
broadly applicable, we will (as we have been) offer our patches
upstream.
(BTW does anyone know offhand of a good reference for what's supposed
to happen when you end up with conflicting shared-lib sub-depends?
I.e. libfoo -> libbar -> libbaz1
-> libbax -> libbaz2
so that libfoo is indirectly linked against two versions of libbaz?
I've received conflicting info, including some anecdotal evidence
that libfoo can actually end up with access to a mixture of symbols
from both versions of libbaz. If true, this would make it extremely
difficult to actually use a "version check" function to make sure you
loaded and were calling functions from the version you expected...)
Thanks, and hope this helps.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
