libjvm missing .so version number

[Andrew Haley]

Andrew Haley writes:
 > Jack Howarth writes:
 > 
 >  >     Shouldn't the shared libraries installed in lib/gcj-4.x.x have
 >  > .so version numbers since they appear to be shared libraries and
 >  > not modules ala python? Specifically on Darwin we see libjvm.dylib
 >  > built without an associated .so version number.
 > 
 > Sounds like a Darwin bug.  On GNU/Linux we have 
 > 
 > lrwxrwxrwx 1 aph aph        15 Jul 28 17:08 /home/aph/install/lib64/libgcj.so -> libgcj.so.7.0.0*
 > lrwxrwxrwx 1 aph aph        15 Jul 28 17:08 /home/aph/install/lib64/libgcj.so.7 -> libgcj.so.7.0.0*
 > -rwxr-xr-x 1 aph aph  84086938 Jul 28 17:08 /home/aph/install/lib64/libgcj.so.7.0.0*

Duh.  I didn't take the time properly to read your message.  Sorry.

 $ ls -l ~/gcc/gcj-eclipse-merge-branch/install/lib/gcj-4.3.0/
total 144
-rw-r--r-- 1 aph aph     0 Nov 20 17:27 classmap.db
-rw-r--r-- 1 aph aph 60920 Nov 20 17:27 libjvm.a
-rwxr-xr-x 1 aph aph  1540 Nov 20 17:27 libjvm.la*
-rwxr-xr-x 1 aph aph 54813 Nov 20 17:27 libjvm.so*

I see what you mean.  What problem are you trying to solve, exactly?
We don't want this DSO to be re-versioned with every libgcj version,
because people would then have to rebuild their executables when
upgrading gcj.  We don't want that.

Andrew.