Re: libjvm missing .so version number

[Jack Howarth <howarth at bromo dot msbb dot uc dot edu>]

Okay. One last question...if we only dlopen libjvm and the other
shared libraries created there and never directly link them in,
why are we bothering to create static versions? On Darwin PPC,
I end up with both a libjvm.dylib and a libjvm.a. Shouldn't we
kill off the static lib builds for that those libraries?
               Jack

On Tue, Nov 21, 2006 at 01:47:47PM -0500, Thomas Fitzsimmons wrote:
> Hi,
> 
> David Daney wrote:
> >Jack Howarth wrote:
> >>Andrew,
> >>   I am just trying to find out if there are any
> >>rules in gcc development requiring shared libraries
> >>to have some so version number. Also, I don't see
> >>that adding one would present a huge problem. Why
> >>can't the files in lib/gcj-4.x.x have their own
> >>so version number that is independent of the one
> >>for libgcj? As long as the ABI for those shared
> >>libs don't change, I don't see why their so version
> >>can't stay at .0 or .1.
> >>           Jack
> >
> >The library in question (libjvm.so) has different requirements than the 
> >rest of the libraries associated with gcj.  It has to maintain ABI 
> >compatibility with an external specification (Sun's JNI specification). 
> > So the rules governing its versioning would be different than the rules 
> >for libgcj.so.
> >
> >Another thing to consider is that libjvm should be loaded via the 
> >dlopen() mechanism and is not directly linked to the executable.  This 
> >eliminates the need or usefulness of any versioning.
> 
> Right, we put any libraries that are meant to be dlopen'd, either by 
> external applications or by the libgcj runtime itself, in lib/gcj-x.x.x.  
> These libraries are unversioned, as dlopen'd libraries should be, and so we 
> install them in a versioned directory so that parallel libgcj installations 
> don't conflict.
> 
> >
> >This said, I don't see that there would be any harm in giving it a 
> >version.  But once done, the version would never be changed.
> 
> Actually, for binary compatibility with Sun, we need the SONAME of e.g. 
> libjvm.so to be "libjvm.so" and not something versioned like "libjvm.so.1". 
> And since all programs using libjvm should be dlopening the unversioned 
> library, we shouldn't provide the ability to link directly to a versioned 
> libjvm.
> 
> Tom