Re: [patch] search for versioned shared libraries

[Thomas Fitzsimmons <fitzsim at redhat dot com>]

On Wed, 2005-03-16 at 11:57 -0500, Bryce McKinlay wrote:
> Thomas Fitzsimmons wrote:
> 
> >This patch makes libltdl search for versioned .sos in addition to .la
> >and unversioned .so files.  The search order
> >is .la, .so.${libgcj_major_version}, .so.  This search order is useful
> >when multiple versions of the same .so are installed in the same place.
> >The unversioned .la file can be removed and the proper library will
> >always be resolved.
> >
> >Also, there was a Makefile.am bug that prevented libgcj.so from being
> >linked when libltdl was modified.  I've included a fix in this patch.
> >
> >OK to commit?
> >  
> >
> 
> I'm not sure that modifying ltdl to implement this is a good idea. 
> Firstly, it creates potential maintainance headaches because we're 
> diverging from the upstream sources. Have you asked the libtool/ltdl 
> guys if they want to implement something like this?

No, not yet.

>  Also, implementing 
> it at the ltdl level could create inconsistent behaviour for, say, 
> loading a 3rd party JNI library, where a different version might get 
> loaded in libgcj (for the same Java code) compared to other VMs.
> 

Maybe, but that seems unlikely.  Aren't JNI libraries usually shipped
with just the .so extension?  In any case, I don't think there's a
formal versioning scheme for JNI libraries.

> Perhaps you can explain the motivation for this patch? Is the idea to 
> allow 3rd party packages/libraries to append libgcj's "ABI version 
> number" to their soname, so its clear which ABI they were compiled for? 
> Or is it just so that the correct versions of libgcj's own libraries can 
> be found when multiple versions are installed in the same place?
> 

Yes, I wrote this patch so that two versions of the peer library could
be installed in the same directory and the proper one would still be
loaded.  e.g.

/usr/lib/lib-gnu-java-awt-peer-gtk.so.5
/usr/lib/lib-gnu-java-awt-peer-gtk.so.6

> If its the later, maybe a naming convention like 
> libwhatever-<gcjversion>.so would be better? This way, the version could 
> be appended by libgcj before it calls into ltdl.
> 

Well, currently we load gnu.java.awt.peer.gtk.GtkToolkit using
Class.forName.  Are you suggesting we make Class.forName's resolution
process version-aware for a list libgcj-specific libraries/packages?

Tom