libjvm missing .so version number

[Thomas Fitzsimmons]

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