Re: Putting .so symlinks in libs package for dlopen()ing?
On Wed, Dec 11, 2002 at 01:06:15AM -0600, Rob Browning wrote:
> Timshel Knoll <firstname.lastname@example.org> 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
Yeah, this would be great!
> (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...)
Why? With dlsym(), you pass a handle to the particular library
handle (that you got from dlopen()). The version check you're
doing is relevant to the library version that piece of code intends