[arch-dev-public] new gcc compiler in testing, better java support now
A new compiler snapshot has been uploaded to testing. Lots of new things, many bugfixes, etc. The most important thing here is that gcc-gcj uses eclipse-ecj to compile itself and all programs compiled with gcj. This makes gcc-gcj completely java 5.0 compatible. This package also includes a web plugin, which is far from completed though. This is important for AMD64 users, as Sun doesn't provide one in the official jre package. As a downsides of all these patches, libgcc_s.so now exports a GCC_4.2.0 symbol that wasn't in older releases. Be very careful with this one when building packages for extra/current or community with these compilers, as binaries that link in this versioned symbol will fail to run on older libgcc_s.so libraries. If all is fine with these new compilers, I'll move them into current and extra in a short while. Happy compiling!
Am Mon, 30 Apr 2007 15:10:00 +0200 schrieb Jan de Groot <jan@jgc.homeip.net>:
A new compiler snapshot has been uploaded to testing. Lots of new things, many bugfixes, etc. The most important thing here is that gcc-gcj uses eclipse-ecj to compile itself and all programs compiled with gcj. This makes gcc-gcj completely java 5.0 compatible. This package also includes a web plugin, which is far from completed though. This is important for AMD64 users, as Sun doesn't provide one in the official jre package.
As a downsides of all these patches, libgcc_s.so now exports a GCC_4.2.0 symbol that wasn't in older releases. Be very careful with this one when building packages for extra/current or community with these compilers, as binaries that link in this versioned symbol will fail to run on older libgcc_s.so libraries.
If all is fine with these new compilers, I'll move them into current and extra in a short while.
Happy compiling!
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
hm. i think it's not worth to risk any breakage at this moment. gcc4.2.0 has reached rc2 and shouldn't be that far away. i dislike taking over that much patches from another distribution just to make it right now work with the backported gcj-ecj. i suggest to wait for gcc4.2.0 release to ship that with java5 support. should be less risky and will probably work without that damn long patchlist. Andy
On Tue, 2007-05-01 at 20:48 +0200, Andreas Radke wrote:
Am Mon, 30 Apr 2007 15:10:00 +0200 schrieb Jan de Groot <jan@jgc.homeip.net>:
hm. i think it's not worth to risk any breakage at this moment. gcc4.2.0 has reached rc2 and shouldn't be that far away. i dislike taking over that much patches from another distribution just to make it right now work with the backported gcj-ecj.
i suggest to wait for gcc4.2.0 release to ship that with java5 support. should be less risky and will probably work without that damn long patchlist.
These patches are either backports from 4.2.0 or regression fixes in 4.1.2. I looked carefully at which patches to merge, many of debians patches are not useful for us since we either don't support those architectures or don't have any use for them (we don't have ada compilers for example). The patch that introduces the 4.2.0 symbol is actually a fixed version of what we were using for that dwarf-2 backport I made a long while ago. About 4.2.0: there's some regressions in that release, they're releasing that anyways. We will have to wait for java 5.0 support again, as 4.2.0 doesn't merge it. Instead, we have to pick stuff from fedora's branch anyways with 4.2.0, putting us in the same position as we're now.
participants (2)
-
Andreas Radke
-
Jan de Groot