Re: Putting .so symlinks in libs package for dlopen()ing?

[Andrew Clausen]

On Wed, Dec 11, 2002 at 01:06:15AM -0600, Rob Browning wrote:
> Timshel Knoll <address@hidden> 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.

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
to use.

Cheers,
Andrew