libjvm missing .so version number

Tue Nov 21 16:59:00 GMT 2006

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.