[patch] [java] bump libgcj soname

[patch] [java] bump libgcj soname

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]

bump the libgcj soname on the trunk, as done for every release cycle, and update
the cygwin/mingw32 files.

ok for the trunk?

  Matthias



[-- Attachment #2: gcjversion.diff --]
[-- Type: text/x-patch, Size: 1591 bytes --]

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

Re: [patch] [java] bump libgcj soname

[Jakub Jelinek]

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

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

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

Re: [patch] [java] bump libgcj soname

[Jakub Jelinek]

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

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

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

Re: [patch] [java] bump libgcj soname

[Jakub Jelinek]

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

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

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

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

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.

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

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

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

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.

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On 02.01.2016 17:11, Andrew Haley wrote:
> 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.

Right, but this no change compared to the 4.x.y releases.

This is what I committed to the trunk.

So what to do with the gcc-5 branch? Apply the same patch to jvm.h, or fix the 
minor version to 3? The latter would be compatible at least with the 5.3 release.

Matthias



[-- Attachment #2: version.diff --]
[-- Type: text/x-diff, Size: 1059 bytes --]

2016-01-03  Matthias Klose  <doko@ubuntu.com>

	* libtool-version: Bump soversion.
	* include/jvm.h (GCJ_CXX_ABI_VERSION): Don't encode __GNUC_MINOR__.

 
Index: libjava/include/jvm.h
===================================================================
--- libjava/include/jvm.h	(revision 232039)
+++ libjava/include/jvm.h	(working copy)
@@ -686,7 +686,7 @@
 					  loader.  */
 
 // These are used to find ABI versions we recognize.
-#define GCJ_CXX_ABI_VERSION (__GNUC__ * 100000 + __GNUC_MINOR__ * 1000)
+#define GCJ_CXX_ABI_VERSION (__GNUC__ * 100000)
 
 // This is the old-style BC version ID used by GCJ 4.0.0.
 #define OLD_GCJ_40_BC_ABI_VERSION (4 * 10000 + 0 * 10 + 5)
Index: libjava/libtool-version
===================================================================
--- libjava/libtool-version	(revision 232039)
+++ 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

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 03/01/16 11:38, Matthias Klose wrote:
> On 02.01.2016 17:11, Andrew Haley wrote:
>> 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.
> 
> Right, but this no change compared to the 4.x.y releases.
> 
> This is what I committed to the trunk.
> 
> So what to do with the gcc-5 branch? Apply the same patch to jvm.h, or fix the 
> minor version to 3? The latter would be compatible at least with the 5.3 release.

Neither.  If you link a program with libgcj then you need to recompile
it when a new version of libgcj comes along.  It has always been this
way.  Why change this rule now, at this stage of GCJ's life?

Andrew.

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

On 03.01.2016 15:17, Andrew Haley wrote:
> On 03/01/16 11:38, Matthias Klose wrote:
>> On 02.01.2016 17:11, Andrew Haley wrote:
>>> 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.
>>
>> Right, but this no change compared to the 4.x.y releases.
>>
>> This is what I committed to the trunk.
>>
>> So what to do with the gcc-5 branch? Apply the same patch to jvm.h, or fix the
>> minor version to 3? The latter would be compatible at least with the 5.3 release.
>
> Neither.  If you link a program with libgcj then you need to recompile
> it when a new version of libgcj comes along.  It has always been this
> way.

No, libgcj versions up to 4.9.3 didn't change the value for releases taken from 
the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same 
GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* GCJ_CXX_ABI_VERSIONs.

> Why change this rule now, at this stage of GCJ's life?

This was changed by the change of the version schema, an unintential change for 
GCJ_CXX_ABI_VERSION.  I want to keep it that way, not change it with every 
release from the gcc-5 branch.

Matthias

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 03/01/16 15:52, Matthias Klose wrote:
> No, libgcj versions up to 4.9.3 didn't change the value for releases taken from 
> the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same 
> GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* GCJ_CXX_ABI_VERSIONs.
> 
>> > Why change this rule now, at this stage of GCJ's life?
> This was changed by the change of the version schema, an unintential change for 
> GCJ_CXX_ABI_VERSION.  I want to keep it that way, not change it with every 
> release from the gcc-5 branch.

Because effectively we've done an arithmetic shift left on the GCC version
numbering, I guess?  So where we would have had 5.1.1, 5.1.2, 5.1.3, we now
have 5.1, 5.2, 5.3?

If that's the idea, your patch is OK.

Thanks,

Andrew.

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]

On 03.01.2016 17:23, Andrew Haley wrote:
> On 03/01/16 15:52, Matthias Klose wrote:
>> No, libgcj versions up to 4.9.3 didn't change the value for releases taken from
>> the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same
>> GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* GCJ_CXX_ABI_VERSIONs.
>>
>>>> Why change this rule now, at this stage of GCJ's life?
>> This was changed by the change of the version schema, an unintential change for
>> GCJ_CXX_ABI_VERSION.  I want to keep it that way, not change it with every
>> release from the gcc-5 branch.
>
> Because effectively we've done an arithmetic shift left on the GCC version
> numbering, I guess?  So where we would have had 5.1.1, 5.1.2, 5.1.3, we now
> have 5.1, 5.2, 5.3?

yes, exactly.

> If that's the idea, your patch is OK.

committed the attached patch to the gcc-5-branch.

Matthias




[-- Attachment #2: version.diff --]
[-- Type: text/x-diff, Size: 846 bytes --]

2016-01-03  Matthias Klose  <doko@ubuntu.com>

	* include/jvm.h (GCJ_CXX_ABI_VERSION): Freeze the ABI for releases
	made from the gcc-5-branch.

 
Index: include/jvm.h
===================================================================
--- include/jvm.h	(revision 232040)
+++ include/jvm.h	(working copy)
@@ -686,7 +686,10 @@
 					  loader.  */
 
 // These are used to find ABI versions we recognize.
-#define GCJ_CXX_ABI_VERSION (__GNUC__ * 100000 + __GNUC_MINOR__ * 1000)
+// GCC 5 changed the versioning schema; the __GNUC_MINOR__ is not anymore
+// a part of a GCC release series.  Freeze the ABI on the gcc-5-branch with
+// the value of the GCC 5.3 release.
+#define GCJ_CXX_ABI_VERSION (__GNUC__ * 100000 + 3 * 1000)
 
 // This is the old-style BC version ID used by GCJ 4.0.0.
 #define OLD_GCJ_40_BC_ABI_VERSION (4 * 10000 + 0 * 10 + 5)

Re: [patch] [java] bump libgcj soname

[Mike Stump]

On Jan 3, 2016, at 9:34 AM, Matthias Klose <doko@ubuntu.com> wrote:
> On 03.01.2016 17:23, Andrew Haley wrote:
>> On 03/01/16 15:52, Matthias Klose wrote:
>>> No, libgcj versions up to 4.9.3 didn't change the value for releases taken from
>>> the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same
>>> GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* GCJ_CXX_ABI_VERSIONs.
>>> 
>>>>> Why change this rule now, at this stage of GCJ's life?
>>> This was changed by the change of the version schema, an unintential change for
>>> GCJ_CXX_ABI_VERSION.  I want to keep it that way, not change it with every
>>> release from the gcc-5 branch.
>> 
>> Because effectively we've done an arithmetic shift left on the GCC version
>> numbering, I guess?  So where we would have had 5.1.1, 5.1.2, 5.1.3, we now
>> have 5.1, 5.2, 5.3?
> 
> yes, exactly.

But, isn’t there a trunk version of this patch?  I mean, the same issue applies to it and gcc 6, gcc 7 and gcc 8, no?

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

On 03.01.2016 20:01, Mike Stump wrote:
> On Jan 3, 2016, at 9:34 AM, Matthias Klose <doko@ubuntu.com> wrote:
>> On 03.01.2016 17:23, Andrew Haley wrote:
>>> On 03/01/16 15:52, Matthias Klose wrote:
>>>> No, libgcj versions up to 4.9.3 didn't change the value for releases taken from
>>>> the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same
>>>> GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* GCJ_CXX_ABI_VERSIONs.
>>>>
>>>>>> Why change this rule now, at this stage of GCJ's life?
>>>> This was changed by the change of the version schema, an unintential change for
>>>> GCJ_CXX_ABI_VERSION.  I want to keep it that way, not change it with every
>>>> release from the gcc-5 branch.
>>>
>>> Because effectively we've done an arithmetic shift left on the GCC version
>>> numbering, I guess?  So where we would have had 5.1.1, 5.1.2, 5.1.3, we now
>>> have 5.1, 5.2, 5.3?
>>
>> yes, exactly.
>
> But, isnÂ’t there a trunk version of this patch?  I mean, the same issue applies to it and gcc 6, gcc 7 and gcc 8, no?

yes, r232040.

Re: [patch] [java] bump libgcj soname

[Andrew Hughes]

----- 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
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: [patch] [java] bump libgcj soname

[Jakub Jelinek]

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

Re: [patch] [java] bump libgcj soname

[Andrew Hughes]

----- 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
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07