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

[Rob Browning]

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.

(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