decoupling libgcj from gcc.src.rpm

[Anthony Green]

FC5 has been kind of frustrating from a libgcj perspective.  We've had to
wait extra-long for new gcc RPMS in order to get critical libgcj fixes
out (for instance 4 or 5 weeks to get gc deadlock update out).  I know
people have talked about separating libgcj from gcc in the past.  I
don't know those conversations ever ended, but it would be really nice
if we could do something for FC6.

I think the simplest approach would be for jakub to continue building
gcc RPMS as is (including building libgcj and running gcj testsuite),
but then delete libgcj after install and don't build the libgcj
sub-packages.  The gcc/libjava directory would still be part of the gcc
SRPM and would get tested as before.

Then we could simply maintain a separate SRPM for libgcj, and not be
shackled to the gcc update schedule.  The SRPM would only have to
contain the appropriate target directories, and we could incorporate
mauve testing into the release process.

I think this will be particularly important if we manage to get
something like gcjwebplugin with the new whitelist feature into FC6.
We may want to push out GUI and security updates on a much more frequent
basis than is reasonable for gcc.

Comments?

AG

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  FC5 has been kind of frustrating from a libgcj perspective. 
> We've had to
>  wait extra-long for new gcc RPMS in order to get critical libgcj fixes
>  out (for instance 4 or 5 weeks to get gc deadlock update out).  I know
>  people have talked about separating libgcj from gcc in the past.  I
>  don't know those conversations ever ended, but it would be really nice
>  if we could do something for FC6. 
While I have absolutely nothing to do with Fedora policy, I feel your
pain with having to wait for gcc in order to do Java development.

This is just the unfortunate consequence of having libgcj at all.
Hopefully someone will eventually try to move forward and separate
libgcj/classpath from gcc entirely.

Moreover, gcc traditionally moves at a rather slow place whereas
classpath is moving pretty rapidly lately.

>  I think this will be particularly important if we manage to get
>  something like gcjwebplugin with the new whitelist feature into FC6.
>  We may want to push out GUI and security updates on a much more frequent
>  basis than is reasonable for gcc. 
Maybe this is too bold a request for FC5, but I would even love to see
the latest libgcj HEAD used, so that we can have the latest classpath,
0.91 instead of being stuck in the ``stonegae'' with 0.20 or whatever
version it is (albeit with patches).

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFEhhgWN5thZBYlTwkRAs21AJ0WzKEDGbi+wtIINgriFyTsd68SZQCdFnr8
> wsEBW/1MW0Le1hp0NRcTN3I=
> =vQ8z
> -----END PGP SIGNATURE-----

[Andrew Overholt]

* Anthony Green <green(a)redhat.com&gt; [2006-06-06 18:50]:
>  
>  Comments? 
While I don't have anything technical to add -- I know Jakub, Tom Tromey,
and Andrew Haley will -- I would like to say that this would be a big plus
from the Eclipse side of things.

Andrew

[Caolán McNamara]

On Tue, 2006-06-06 at 21:51 -0400, Andrew Overholt wrote:
>  * Anthony Green <green(a)redhat.com&gt; [2006-06-06 18:50]:
>  > 
>  > Comments?
>  
>  While I don't have anything technical to add -- I know Jakub, Tom Tromey,
>  and Andrew Haley will -- I would like to say that this would be a big plus
>  from the Eclipse side of things. 
Indeed, having a longterm undelivered fix for the OOo xslt export
crasher https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182263
can be real frustrating.

C.

[Bryce McKinlay]

David Walluck wrote:
>  While I have absolutely nothing to do with Fedora policy, I feel
> your
>  pain with having to wait for gcc in order to do Java development.
>
>  This is just the unfortunate consequence of having libgcj at all.
>  Hopefully someone will eventually try to move forward and separate
>  libgcj/classpath from gcc entirely.
>     
While in some ways it would be nice to separate libgcj from gcc, it is 
problematic to do so because the ABI is still evolving. While we usually 
try to keep the runtime backwards-compatible with old binaries, 
developers would need to be careful to keep their runtime up-to-date. 
This would quickly become painful, especially for GCC developers who 
just want to test that their changes don't break Java. Hopefully, in the 
future when the ABI has stabilized and pretty much any combination of 
compiler and libgcj will work together nicely, this will be the right 
thing to do.

In the mean time, I think separating them into different SRPMs for 
Fedora is a great idea and would solve most of the problem.

>  Maybe this is too bold a request for FC5, but I would even love to
> see
>  the latest libgcj HEAD used, so that we can have the latest classpath,
>  0.91 instead of being stuck in the ``stonegae'' with 0.20 or whatever
>  version it is (albeit with patches).
>     
For FC6, we are going to backport the latest libgcj/classpath.

Bryce

[Michael Koch]

Anthony Green <green@...> writes:

>  FC5 has been kind of frustrating from a libgcj perspective. 
> We've had to
>  wait extra-long for new gcc RPMS in order to get critical libgcj fixes
>  out (for instance 4 or 5 weeks to get gc deadlock update out).  I know
>  people have talked about separating libgcj from gcc in the past.  I
>  don't know those conversations ever ended, but it would be really nice
>  if we could do something for FC6.
>  
>  I think the simplest approach would be for jakub to continue building
>  gcc RPMS as is (including building libgcj and running gcj testsuite),
>  but then delete libgcj after install and don't build the libgcj
>  sub-packages.  The gcc/libjava directory would still be part of the gcc
>  SRPM and would get tested as before.
>  
>  Then we could simply maintain a separate SRPM for libgcj, and not be
>  shackled to the gcc update schedule.  The SRPM would only have to
>  contain the appropriate target directories, and we could incorporate
>  mauve testing into the release process.
>  
>  I think this will be particularly important if we manage to get
>  something like gcjwebplugin with the new whitelist feature into FC6.
>  We may want to push out GUI and security updates on a much more frequent
>  basis than is reasonable for gcc.
>  
>  Comments? 
Just to gibe som input from someone independent:

Debian does something like this since some time. We have two source packages,
gcc-4.1 and gcj-4.1. The first builds and packages all of GCC except Java. The
second one builds C/C++/Java and packages only the Java parts. this works quite
good. We take care that both source packages are from the same upstream sources
but its easily possible to add patches and bug fixes to one of the packages and
just rebuild it.

The gcj-4.1 source package builds the binary packages gcj-4.1, gij-4.1, fastjar,
libgcj7 libgcj7-dev libgcj7-dbg, libgcj7-awt, etc.


Cheers,
Michael

[Mark Wielaard]

Hi,

On Thu, 2006-06-08 at 18:39 +0000, Michael Koch wrote:
>  > Then we could simply maintain a separate SRPM for libgcj, and
> not be
>  > shackled to the gcc update schedule.  The SRPM would only have to
>  > contain the appropriate target directories, and we could incorporate
>  > mauve testing into the release process.
>
>  Debian does something like this since some time. We have two source packages,
>  gcc-4.1 and gcj-4.1. The first builds and packages all of GCC except Java. The
>  second one builds C/C++/Java and packages only the Java parts. this works quite
>  good. We take care that both source packages are from the same upstream sources
>  but its easily possible to add patches and bug fixes to one of the packages and
>  just rebuild it. 
It would be nice if we can coordinate the patch-set between fedora and
debian. And maybe, if it all seems to work out find, we could even
suggest that patch-set for a new 4.1.x release. Even if that breaks
binary compatibility. Because if it is what the distributions ship then
it must be good :)

Cheers,

Mark

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Wielaard wrote:
>  It would be nice if we can coordinate the patch-set between fedora
> and
>  debian. And maybe, if it all seems to work out find, we could even
>  suggest that patch-set for a new 4.1.x release. Even if that breaks
>  binary compatibility. Because if it is what the distributions ship then
>  it must be good :) 
I don't know how wise this is, and maybe upstream GCC cares about ABI
compatibility, but I personally don't have a use for it.

And I am sure that along with Debian and the JPackage conglomerate
(Fedora, Mandriva, Red Hat, Suse, etc.) we probably could get everyone
using it for their upcoming releases :)

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFEiLCmN5thZBYlTwkRAoi5AJ44rzoqbTZgibrPptSd6iVU/HXsnQCfaAok
> pIzoD0ay595jWpnmG1Ory8g=
> =/sSC
> -----END PGP SIGNATURE-----

[Anthony Green]

Here's what a libgcj source RPM could look like (using FC5)...

http://people.redhat.com/green/libgcj-4.1.1-1.fc5.src.rpm 

This source RPM builds, so feel free to try it.

You'll see that the SOURCES directory contains a script called
libgcj-copy-source.sh.   This script generates the libgcj source tarball
from portions of the prepped gcc sources.

Using a libgcj source RPM like this means we can easily add our own
patches, rebuild and deploy on a schedule that is independent from the
gcc update schedule.

I'm going to have sporadic email access for the next 10 days or so.  I
just wanted to get this out for comment before I take off.

Thanks,

AG

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
>  I'm going to have sporadic email access for the next 10 days or
> so.  I
>  just wanted to get this out for comment before I take off. 
Well, can't say I didn't try


../../../libjava/java/lang/Class.h: In member function
'java::lang::Class* java::lang::Class::getComponentType()':
../../../libjava/java/lang/Class.h:354: warning: dereferencing
type-punned pointer will break strict-aliasing rules
../../../libjava/exception.cc: In function '_Unwind_Reason_Code
__gcj_personality_v0(int, _Unwind_Action, _Unwind_Exception_Class,
_Unwind_Exception*, _Unwind_Context*)':
../../../libjava/exception.cc:234: error: '_Unwind_GetIPInfo' was not
declared in this scope

But I am having a weird X font issue right now and I can't even read
what this says or what I'm typing :)

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFEiTlkN5thZBYlTwkRAjenAKCEh7wEgu8lf8KWgJKXfdxH2ACSAwCfVDuR
> C2IbV37KbZpdER0zs7/H730=
> =bekM
> -----END PGP SIGNATURE-----

[Tom Tromey]

> >>>> "Anthony" == Anthony Green
> <green(a)redhat.com&gt; writes: 
Anthony> I know people have talked about separating libgcj from gcc in
Anthony> the past.

Yeah, it is a good idea.  I'm sorry for not backing Tom F. when he
brought it up internally.

I thought that we'd have problems with the C++ ABI, but it occurs to
me now that splitting the RPMs and breaking the ABI are different
issues.  There's no reason to assume that they are related.

Anthony> I think this will be particularly important if we manage to
Anthony> get something like gcjwebplugin with the new whitelist
Anthony> feature into FC6. We may want to push out GUI and security
Anthony> updates on a much more frequent basis than is reasonable for
Anthony> gcc.

I'm convinced.

Once we switch to ecj I think we should go even further.  We should
make -findirect-dispatch the default and we should push
C++-ABI-breaking changes.  The only difficulty here is that frysk
uses the C++ ABI.

Tom

[Andrew Haley]

Tom Tromey writes:

>  We should make -findirect-dispatch the default and we should push
>  C++-ABI-breaking changes.  The only difficulty here is that frysk
>  uses the C++ ABI. 
Why is that an issue?  Surely if we change the default to indirect,
frysk will also change.  I'm assuming the frysk build uses whatever
the default happens to be...

Andrew.

[Anthony Green]

On Fri, 2006-06-09 at 05:03 -0400, David Walluck wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Anthony Green wrote:
>  > I'm going to have sporadic email access for the next 10 days or so.  I
>  > just wanted to get this out for comment before I take off.
>  
>  Well, can't say I didn't try 
I can't reproduce this problem.  Could somebody else please try?

Thanks,

AG



>  
>  ../../../libjava/java/lang/Class.h: In member function
>  'java::lang::Class* java::lang::Class::getComponentType()':
>  ../../../libjava/java/lang/Class.h:354: warning: dereferencing
>  type-punned pointer will break strict-aliasing rules
>  ../../../libjava/exception.cc: In function '_Unwind_Reason_Code
>  __gcj_personality_v0(int, _Unwind_Action, _Unwind_Exception_Class,
>  _Unwind_Exception*, _Unwind_Context*)':
>  ../../../libjava/exception.cc:234: error: '_Unwind_GetIPInfo' was not
>  declared in this scope
>  
>  But I am having a weird X font issue right now and I can't even read
>  what this says or what I'm typing :)
>  
>  - --
>  Sincerely,
>  
>  David Walluck
>  <david(a)zarb.org&gt;
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.2.2 (GNU/Linux)
> >  Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
> >  
> >  iD8DBQFEiTlkN5thZBYlTwkRAjenAKCEh7wEgu8lf8KWgJKXfdxH2ACSAwCfVDuR
> >  C2IbV37KbZpdER0zs7/H730=
> >  =bekM
> >  -----END PGP SIGNATURE----- 
>

[Tom Tromey]

> >>>> "Andrew" == Andrew Haley
> <aph(a)redhat.com&gt; writes: 
Andrew> Tom Tromey writes:
> > We should make -findirect-dispatch the default and we should
> push
> > C++-ABI-breaking changes.  The only difficulty here is that frysk
> > uses the C++ ABI. 
Andrew> Why is that an issue?  Surely if we change the default to indirect,
Andrew> frysk will also change.  I'm assuming the frysk build uses whatever
Andrew> the default happens to be...

No, frysk uses CNI, which only "works" with indirect dispatch.
In particular I think if we break C++ ABI in the core, frysk will
break even if it is BC-compiled.

Tom

[Andrew Haley]

Tom Tromey writes:
>  >>>>> "Andrew" == Andrew Haley
> <aph(a)redhat.com&gt; writes:
>  
>  Andrew> Tom Tromey writes:
>  >> We should make -findirect-dispatch the default and we should push
>  >> C++-ABI-breaking changes.  The only difficulty here is that frysk
>  >> uses the C++ ABI.
>  
>  Andrew> Why is that an issue?  Surely if we change the default to indirect,
>  Andrew> frysk will also change.  I'm assuming the frysk build uses whatever
>  Andrew> the default happens to be...
>  
>  No, frysk uses CNI, which only "works" with indirect dispatch. 
Ah, of course, I forgot.

>  In particular I think if we break C++ ABI in the core, frysk will
>  break even if it is BC-compiled. 
It will.  Sorry for the noise.

Andrew.

[Andrew Cagney]

Tom Tromey wrote:
> >>>>> "Andrew" == Andrew Haley
> <aph(a)redhat.com&gt; writes:
> >>>>>             
>
>  Andrew> Tom Tromey writes:
>    
> >> We should make -findirect-dispatch the default and we should push
> >> C++-ABI-breaking changes.  The only difficulty here is that frysk
> >> uses the C++ ABI.
> >>       
>
>  Andrew> Why is that an issue?  Surely if we change the default to indirect,
>  Andrew> frysk will also change.  I'm assuming the frysk build uses whatever
>  Andrew> the default happens to be...
>
>  No, frysk uses CNI, which only "works" with indirect dispatch.
>  In particular I think if we break C++ ABI in the core, frysk will
>  break even if it is BC-compiled.
>     
Er, given libgcj is implemented using CNI, how is that different?

Andrew

[Tom Tromey]

> >>>> "Andrew" == Andrew Cagney
> <cagney(a)redhat.com&gt; writes: 
Andrew> Er, given libgcj is implemented using CNI, how is that different?

We always ship an internally consistent libgcj.

The dangerous case here is where we update libgcj but we don't rebuild
frysk.  In this case, e.g., frysk may think class X has one size
whereas in the new libgcj it actually has a different size.

The best scenario would be to fix CNI.  I'm kind of assuming we won't
do that anytime soon though.

Tom

[Mark Wielaard]

On Mon, 2006-06-12 at 10:52 -0600, Tom Tromey wrote:
>  The best scenario would be to fix CNI.  I'm kind of assuming we
> won't
>  do that anytime soon though. 
What would be needed to "fix CNI"?
Are there any drawbacks to fixing it?

Cheers,

Mark

[Andrew Haley]

Mark Wielaard writes:
>  On Mon, 2006-06-12 at 10:52 -0600, Tom Tromey wrote:
>  > The best scenario would be to fix CNI.  I'm kind of assuming we won't
>  > do that anytime soon though.
>  
>  What would be needed to "fix CNI"? 
Make CNI use Java's linkage, not that of C++.

>  Are there any drawbacks to fixing it? 
Not much.  A slight loss of speed.

Andrew.

[Tom Tromey]

> >>>> "Andrew" == Andrew Haley
> <aph(a)redhat.com&gt; writes: 
> > Are there any drawbacks to fixing it? 
Andrew> Not much.  A slight loss of speed.

Yeah, just to clarify my earlier statement -- I think we want to fix
it.  We just ran out of time in this release cycle.  Or to put it
another way, there were more important things to do.

Tom

[Anthony Green]

Jakub - I should have copied you on the original thread.

We had been discussing decoupling the libgcj SRPM from the gcc SRPM so
we can push java runtime fixes out more frequently than gcc updates.
The idea would be for you to continue to build & test libgcj as part of
the gcc package, but delete it after installation and don't package it.
Then we'll just make a new SRPM based on the gcc sources that we can
patch and push out on a more frequent basis.  What do you think of this
idea?

AG

On Fri, 2006-06-09 at 01:17 -0700, Anthony Green wrote:
>  Here's what a libgcj source RPM could look like (using FC5)...
>  
>  http://people.redhat.com/green/libgcj-4.1.1-1.fc5.src.rpm 
>  
>  This source RPM builds, so feel free to try it.
>  
>  You'll see that the SOURCES directory contains a script called
>  libgcj-copy-source.sh.   This script generates the libgcj source tarball
>  from portions of the prepped gcc sources.
>  
>  Using a libgcj source RPM like this means we can easily add our own
>  patches, rebuild and deploy on a schedule that is independent from the
>  gcc update schedule.
>  
>  I'm going to have sporadic email access for the next 10 days or so.  I
>  just wanted to get this out for comment before I take off.
>  
>  Thanks,
>  
>  AG
>  
>  
>  --
>  fedora-devel-java-list mailing list
>  fedora-devel-java-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

[Tom Tromey]

> >>>> "Anthony" == Anthony Green
> <green(a)redhat.com&gt; writes: 
Anthony> We had been discussing decoupling the libgcj SRPM from the
Anthony> gcc SRPM so we can push java runtime fixes out more
Anthony> frequently than gcc updates.

FWIW the primary motivation is so that we can push out libgcj bug
fixes more rapidly.  For instance, the zip fix for RSSOwl... and
Anthony has mentioned some XML fix for OO.o, but I don't remember
that one.

Tom

[Anthony Green]

On Tue, 2006-07-18 at 12:17 -0600, Tom Tromey wrote:
>  FWIW the primary motivation is so that we can push out libgcj bug
>  fixes more rapidly.  For instance, the zip fix for RSSOwl... and
>  Anthony has mentioned some XML fix for OO.o, but I don't remember
>  that one. 
Actually, it wasn't an XML fix - it was a fix that impacted OO.o xslt
output:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182263

There were other bugs as well, like the Eclipse-impacting deadlock
problem.

AG