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
-----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@zarb.org
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
* Anthony Green green@redhat.com [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
On Tue, 2006-06-06 at 21:51 -0400, Andrew Overholt wrote:
- Anthony Green green@redhat.com [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.
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
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
-----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@zarb.org
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
-----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@zarb.org
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@zarb.org -----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-----
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
"Anthony" == Anthony Green green@redhat.com 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
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
"Anthony" == Anthony Green green@redhat.com 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
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.
"Andrew" == Andrew Haley aph@redhat.com 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
Tom Tromey writes:
"Andrew" == Andrew Haley aph@redhat.com 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.
Tom Tromey wrote:
"Andrew" == Andrew Haley aph@redhat.com 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
"Andrew" == Andrew Cagney cagney@redhat.com 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 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.
"Andrew" == Andrew Haley aph@redhat.com 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
java-devel@lists.fedoraproject.org
-
Andrew Cagney -
Andrew Haley -
Andrew Overholt -
Anthony Green -
Bryce McKinlay -
Caolán McNamara -
David Walluck -
Mark Wielaard -
Michael Koch -
Tom Tromey