| Message ID | 55365991.4030806@ubuntu.com |
|---|---|
| State | New |
| Headers | show |
On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote:
> bump the libgcj soname on the trunk, as done for every release cycle,
Is that really needed though these days?
Weren't there basically zero changes to libjava (both libjava and
libjava/classpath) in the last 2 or more years?
The few ones were mostly updating Copyright notices, minor configure
changes, but I really haven't seen anything ABI changing for quite a while.
Jakub
On 04/21/2015 04:11 PM, Jakub Jelinek wrote: > On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: >> bump the libgcj soname on the trunk, as done for every release cycle, > > Is that really needed though these days? > Weren't there basically zero changes to libjava (both libjava and > libjava/classpath) in the last 2 or more years? > The few ones were mostly updating Copyright notices, minor configure > changes, but I really haven't seen anything ABI changing for quite a while. yes, the GCC version is embedded in the GCJ_VERSIONED_LIBDIR which is defined as gcjsubdir=gcj-$gcjversion-$libgcj_soversion dbexecdir='$(toolexeclibdir)/'$gcjsubdir
On Tue, Apr 21, 2015 at 04:16:18PM +0200, Matthias Klose wrote: > On 04/21/2015 04:11 PM, Jakub Jelinek wrote: > > On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: > >> bump the libgcj soname on the trunk, as done for every release cycle, > > > > Is that really needed though these days? > > Weren't there basically zero changes to libjava (both libjava and > > libjava/classpath) in the last 2 or more years? > > The few ones were mostly updating Copyright notices, minor configure > > changes, but I really haven't seen anything ABI changing for quite a while. > > yes, the GCC version is embedded in the GCJ_VERSIONED_LIBDIR > > which is defined as > > gcjsubdir=gcj-$gcjversion-$libgcj_soversion > dbexecdir='$(toolexeclibdir)/'$gcjsubdir But why is that an argument for bumping it? If both GCC 5 and GCC 6 will (likely) provide the same ABI in the library, there is no reason not to use the same directory for those. Jakub
On 04/21/2015 04:19 PM, Jakub Jelinek wrote: > On Tue, Apr 21, 2015 at 04:16:18PM +0200, Matthias Klose wrote: >> On 04/21/2015 04:11 PM, Jakub Jelinek wrote: >>> On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: >>>> bump the libgcj soname on the trunk, as done for every release cycle, >>> >>> Is that really needed though these days? >>> Weren't there basically zero changes to libjava (both libjava and >>> libjava/classpath) in the last 2 or more years? >>> The few ones were mostly updating Copyright notices, minor configure >>> changes, but I really haven't seen anything ABI changing for quite a while. >> >> yes, the GCC version is embedded in the GCJ_VERSIONED_LIBDIR >> >> which is defined as >> >> gcjsubdir=gcj-$gcjversion-$libgcj_soversion >> dbexecdir='$(toolexeclibdir)/'$gcjsubdir > > But why is that an argument for bumping it? If both GCC 5 and GCC 6 will > (likely) provide the same ABI in the library, there is no reason not to use > the same directory for those. but currently there are different directories used (gcjversion already changed on the trunk) and compiled into the library. Do you mean that gcjsubdir should be just defined as gcj? Matthias
On Tue, Apr 21, 2015 at 04:29:52PM +0200, Matthias Klose wrote: > On 04/21/2015 04:19 PM, Jakub Jelinek wrote: > > On Tue, Apr 21, 2015 at 04:16:18PM +0200, Matthias Klose wrote: > >> On 04/21/2015 04:11 PM, Jakub Jelinek wrote: > >>> On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: > >>>> bump the libgcj soname on the trunk, as done for every release cycle, > >>> > >>> Is that really needed though these days? > >>> Weren't there basically zero changes to libjava (both libjava and > >>> libjava/classpath) in the last 2 or more years? > >>> The few ones were mostly updating Copyright notices, minor configure > >>> changes, but I really haven't seen anything ABI changing for quite a while. > >> > >> yes, the GCC version is embedded in the GCJ_VERSIONED_LIBDIR > >> > >> which is defined as > >> > >> gcjsubdir=gcj-$gcjversion-$libgcj_soversion > >> dbexecdir='$(toolexeclibdir)/'$gcjsubdir > > > > But why is that an argument for bumping it? If both GCC 5 and GCC 6 will > > (likely) provide the same ABI in the library, there is no reason not to use > > the same directory for those. > > but currently there are different directories used (gcjversion already changed > on the trunk) and compiled into the library. Do you mean that gcjsubdir should > be just defined as gcj? What depends on BASE-VER sure, that is bumped automatically and should track the gcc version. But the soname, which is an unrelated number, there is no point to bump it. If you have a packaging issue, just solve it on the packaging side, but really there is no point to yearly bump a soname of something that doesn't change at all (and is really dead project for many years). Jakub
----- Original Message ----- > On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: > > bump the libgcj soname on the trunk, as done for every release cycle, > > Is that really needed though these days? > Weren't there basically zero changes to libjava (both libjava and > libjava/classpath) in the last 2 or more years? > The few ones were mostly updating Copyright notices, minor configure > changes, but I really haven't seen anything ABI changing for quite a while. > On the Classpath side, there's a bunch of stuff to merge in that would change the ABI. It's a matter of finding a good point at which to do it and time to do so. I keep missing the right point in the gcc lifecycle. > Jakub >
On Tue, Apr 21, 2015 at 01:04:04PM -0400, Andrew Hughes wrote: > ----- Original Message ----- > > On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: > > > bump the libgcj soname on the trunk, as done for every release cycle, > > > > Is that really needed though these days? > > Weren't there basically zero changes to libjava (both libjava and > > libjava/classpath) in the last 2 or more years? > > The few ones were mostly updating Copyright notices, minor configure > > changes, but I really haven't seen anything ABI changing for quite a while. > > > > On the Classpath side, there's a bunch of stuff to merge in that would > change the ABI. It's a matter of finding a good point at which to do it > and time to do so. I keep missing the right point in the gcc lifecycle. Now might be a good time (any time next 6.5 months or so), and if that is done, surely I have no issue with bumping the soname. Jakub
----- Original Message ----- > On Tue, Apr 21, 2015 at 01:04:04PM -0400, Andrew Hughes wrote: > > ----- Original Message ----- > > > On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: > > > > bump the libgcj soname on the trunk, as done for every release cycle, > > > > > > Is that really needed though these days? > > > Weren't there basically zero changes to libjava (both libjava and > > > libjava/classpath) in the last 2 or more years? > > > The few ones were mostly updating Copyright notices, minor configure > > > changes, but I really haven't seen anything ABI changing for quite a > > > while. > > > > > > > On the Classpath side, there's a bunch of stuff to merge in that would > > change the ABI. It's a matter of finding a good point at which to do it > > and time to do so. I keep missing the right point in the gcc lifecycle. > > Now might be a good time (any time next 6.5 months or so), and if that is > done, surely I have no issue with bumping the soname. > Ok, that should be possible. > Jakub >
On 21.04.2015 16:37, Jakub Jelinek wrote: > On Tue, Apr 21, 2015 at 04:29:52PM +0200, Matthias Klose wrote: >> On 04/21/2015 04:19 PM, Jakub Jelinek wrote: >>> On Tue, Apr 21, 2015 at 04:16:18PM +0200, Matthias Klose wrote: >>>> On 04/21/2015 04:11 PM, Jakub Jelinek wrote: >>>>> On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: >>>>>> bump the libgcj soname on the trunk, as done for every release cycle, >>>>> >>>>> Is that really needed though these days? >>>>> Weren't there basically zero changes to libjava (both libjava and >>>>> libjava/classpath) in the last 2 or more years? >>>>> The few ones were mostly updating Copyright notices, minor configure >>>>> changes, but I really haven't seen anything ABI changing for quite a while. >>>> >>>> yes, the GCC version is embedded in the GCJ_VERSIONED_LIBDIR >>>> >>>> which is defined as >>>> >>>> gcjsubdir=gcj-$gcjversion-$libgcj_soversion >>>> dbexecdir='$(toolexeclibdir)/'$gcjsubdir >>> >>> But why is that an argument for bumping it? If both GCC 5 and GCC 6 will >>> (likely) provide the same ABI in the library, there is no reason not to use >>> the same directory for those. >> >> but currently there are different directories used (gcjversion already changed >> on the trunk) and compiled into the library. Do you mean that gcjsubdir should >> be just defined as gcj? > > What depends on BASE-VER sure, that is bumped automatically and should track > the gcc version. But the soname, which is an unrelated number, there is no > point to bump it. If you have a packaging issue, just solve it on the > packaging side, but really there is no point to yearly bump a soname of > something that doesn't change at all (and is really dead project for many > years). preparing for a test rebuild of the archive, and trying to run gcj-dbtool (from GCC 5) with libgcj16 (from GCC 6): $ gcj-dbtool -n /tmp/foo.db libgcj failure: gcj linkage error. Incorrect library ABI version detected. Aborting. Aborted (core dumped) natClassLoader.cc:_Jv_CheckABIVersion checks the ABI version, which is defined as libjava/include/jvm.h:#define GCJ_CXX_ABI_VERSION (__GNUC__ * 100000 + __GNUC_MINOR__ * 1000) so this will be seen with everything directly linked to libgcj with a libgcj16 upgraded to GCC 6. So what to do? Bump the soname, or discard this check? In any case, GCJ_CXX_ABI_VERSION should be changed to not include __GNUC_MINOR__ anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so that it won't change anymore with future releases from the gcc-5 branch? Matthias
On 02/01/16 14:40, Matthias Klose wrote: > > preparing for a test rebuild of the archive, and trying to run gcj-dbtool (from > GCC 5) with libgcj16 (from GCC 6): > > $ gcj-dbtool -n /tmp/foo.db > libgcj failure: gcj linkage error. > Incorrect library ABI version detected. Aborting. > > Aborted (core dumped) > > natClassLoader.cc:_Jv_CheckABIVersion checks the ABI version, which is defined as > > libjava/include/jvm.h:#define GCJ_CXX_ABI_VERSION (__GNUC__ * 100000 + > __GNUC_MINOR__ * 1000) > > so this will be seen with everything directly linked to libgcj with a libgcj16 > upgraded to GCC 6. So what to do? Bump the soname, or discard this check? I'd bump the soname. > In any case, GCJ_CXX_ABI_VERSION should be changed to not include __GNUC_MINOR__ > anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so that it > won't change anymore with future releases from the gcc-5 branch? That's safe only if Classpath and libgcj are not changed at all. I guess we can guarantee that on the gcc-5 branch? Andrew.
On 02.01.2016 16:39, Andrew Haley wrote: > On 02/01/16 14:40, Matthias Klose wrote: >> >> preparing for a test rebuild of the archive, and trying to run gcj-dbtool (from >> GCC 5) with libgcj16 (from GCC 6): >> >> $ gcj-dbtool -n /tmp/foo.db >> libgcj failure: gcj linkage error. >> Incorrect library ABI version detected. Aborting. >> >> Aborted (core dumped) >> >> natClassLoader.cc:_Jv_CheckABIVersion checks the ABI version, which is defined as >> >> libjava/include/jvm.h:#define GCJ_CXX_ABI_VERSION (__GNUC__ * 100000 + >> __GNUC_MINOR__ * 1000) >> >> so this will be seen with everything directly linked to libgcj with a libgcj16 >> upgraded to GCC 6. So what to do? Bump the soname, or discard this check? > > I'd bump the soname. > >> In any case, GCJ_CXX_ABI_VERSION should be changed to not include __GNUC_MINOR__ >> anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so that it >> won't change anymore with future releases from the gcc-5 branch? > > That's safe only if Classpath and libgcj are not changed at all. why? __GNUC_SUBMINOR__ wasn't encoded either for releases up to 4.9.x. Matthias
On 02/01/16 15:53, Matthias Klose wrote: >>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include __GNUC_MINOR__ >>> >> anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so that it >>> >> won't change anymore with future releases from the gcc-5 branch? >> > >> > That's safe only if Classpath and libgcj are not changed at all. > why? Because of the way that gcj's linkage works. If you change any of the vtable/itable indexes your program will crash. Andrew.
gcc/ 2015-04-21 Matthias Klose <doko@ubuntu.com> * config/i386/cygwin.h (LIBGCJ_SONAME): Set libgcj version to -17. * config/i386/mingw32.h (LIBGCJ_SONAME): Set libgcj version to -17. libjava/ 2015-04-21 Matthias Klose <doko@ubuntu.com> * libtool-version: Bump soversion. Index: gcc/config/i386/cygwin.h =================================================================== --- gcc/config/i386/cygwin.h (revision 222268) +++ gcc/config/i386/cygwin.h (working copy) @@ -154,5 +154,5 @@ #define LIBGCC_SONAME "cyggcc_s" LIBGCC_EH_EXTN "-1.dll" /* We should find a way to not have to update this manually. */ -#define LIBGCJ_SONAME "cyggcj" /*LIBGCC_EH_EXTN*/ "-16.dll" +#define LIBGCJ_SONAME "cyggcj" /*LIBGCC_EH_EXTN*/ "-17.dll" Index: gcc/config/i386/mingw32.h =================================================================== --- gcc/config/i386/mingw32.h (revision 222268) +++ gcc/config/i386/mingw32.h (working copy) @@ -254,4 +254,4 @@ #define LIBGCC_SONAME "libgcc_s" LIBGCC_EH_EXTN "-1.dll" /* We should find a way to not have to update this manually. */ -#define LIBGCJ_SONAME "libgcj" /*LIBGCC_EH_EXTN*/ "-16.dll" +#define LIBGCJ_SONAME "libgcj" /*LIBGCC_EH_EXTN*/ "-17.dll" Index: libjava/libtool-version =================================================================== --- libjava/libtool-version (revision 222268) +++ libjava/libtool-version (working copy) @@ -5,4 +5,4 @@ # Note: When changing the version here, please do also update LIBGCJ_SONAME # in gcc/config/i386/cygwin.h and gcc/config/i386/mingw32.h. # CURRENT:REVISION:AGE -16:0:0 +17:0:0