no .so version on libjvm

[Peter O'Gorman]

On Nov 21, 2006, at 8:31 AM, Jack Howarth wrote:

>    I just noticed while tidying the packaging of
> gcc 4.2 for fink that we don't seem to have a .so
> version associated with libjvm (at least for Darwin).
> I get...
>
> otool -L /sw/lib/gcc4/lib/gcj-4.2.0/libjvm.dylib
> /sw/lib/gcc4/lib/gcj-4.2.0/libjvm.dylib:
>         /sw/lib/gcc4/lib/gcj-4.2.0/libjvm.dylib (compatibility  
> version 0.0.0, current version 0.0.0)
>         /sw/lib/gcc4/lib/libgcj.8.dylib (compatibility version  
> 9.0.0, current version 9.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
> current version 88.1.7)
>         /sw/lib/gcc4/lib/libgcc_s.1.dylib (compatibility version  
> 1.0.0, current version 1.0.0)
>
> which seems to conflict with the definition of the compatibility  
> version.
> I understood that to be one greater than the actual .so version  
> (which would
> make our .so version -1). Shouldn't this be fixed for both gcc trunk
> and 4.2 branch?

Hi Jack,
Well, libjava's Makefile.am has:
libjvm_la_LDFLAGS = -avoid-version $(LIBGCJ_LD_SYMBOLIC)

So the lack of versioning would seem to be on purpose. Because the  
library is in a versioned directory this is not a problem, it will be  
in a different versioned directory on a different gcc release.

As for gnu libtool adding 1 to the compatibility and current versions  
on darwin, there is a very simple explanation. Apple's   32 bit  
linker will fail to create a shared library if either compatibility  
or current version is specified and zero - even though zero is the  
default if unspecified. The libtool maintainers at the time added 1  
to the versions to avoid this issue. Note that even though this  
behavior is different with the 64 bit linker, it will never be  
possible to stop adding 1 to the version numbers.

Hope this helps,
Peter