diff mbox

[java] bump libgcj soname

Message ID 56890829.4020601@ubuntu.com
State New
Headers show

Commit Message

Matthias Klose Jan. 3, 2016, 11:38 a.m. UTC
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

Comments

Andrew Haley Jan. 3, 2016, 2:17 p.m. UTC | #1
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.
Matthias Klose Jan. 3, 2016, 3:52 p.m. UTC | #2
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
Andrew Haley Jan. 3, 2016, 4:23 p.m. UTC | #3
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.
diff mbox

Patch

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