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
