[arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages
Hi all, The gcc-4.4.0 toolchain rebuild is now in [testing]. Here is a rough ChangeLog: kernel-headers: - upstream updated (2.6.29.1) glibc: - update cvs snapshot from 2.9 branch - removed glibc-2.5-localedef_segfault-1.patch (old and appears fixed upstream) - removed glibc-2.7-bz4781.patch (rejected upstream as bug in gcc - Andy: please check if your issue is solved) - compress info pages - fix info page handling in install script binutils: - update cvs snapshot from 2.19 branch - remove texinfo dep through install script - add upstream patch to improve -Wl,--as-needed usage - add linker scripts for libbfd.so and libopcodes.so - compress info pages gcc-libs - new makedepends (ppl and cloog-ppl) - removed unneeded bison build patch - removed treelang (done upstream) gcc - removals as in gcc-libs - added dependencies on new packages ppl and cloog-ppl (for graphite optimizations) - update libstdc++ man pages - install license exception - compress info pages I am having great difficultly getting a working gcc-gcj... It builds fine using the gcc-gcj-4.3.x package but when I rebuild eclipse-ecj with the freshly built 4.4.0 package, I can not rebuild gcc-gcj again. Updating eclipse-ecj to the latest build does not fix the issue. After two and a half days of trying to track this down, I am ready to give up. If someone else wants to look at this, go ahead but... Do we really need gcc-gcj, eclipse-ecj and java-gcj-compat any more? Reason I see for removing it: - I can't get it to build - java-gcj-compat provides java-runtime, but I checked six packages in the repos against this and none actually fully worked - which also is very bad as it is the first package found by pacman for java-runtime - we have a free java now in openjdk6 Opinions? Allan
Am Samstag, 25. April 2009 13:15:08 schrieb Allan McRae:
I am having great difficultly getting a working gcc-gcj... It builds fine using the gcc-gcj-4.3.x package but when I rebuild eclipse-ecj with the freshly built 4.4.0 package, I can not rebuild gcc-gcj again. Updating eclipse-ecj to the latest build does not fix the issue. After two and a half days of trying to track this down, I am ready to give up. If someone else wants to look at this, go ahead but...
Do we really need gcc-gcj, eclipse-ecj and java-gcj-compat any more? Reason I see for removing it: - I can't get it to build - java-gcj-compat provides java-runtime, but I checked six packages in the repos against this and none actually fully worked - which also is very bad as it is the first package found by pacman for java-runtime - we have a free java now in openjdk6
Opinions?
gcj is of no use imho. it can be replaced by openjdk. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Am Sat, 25 Apr 2009 21:15:08 +1000 schrieb Allan McRae <allan@archlinux.org>:
Hi all,
The gcc-4.4.0 toolchain rebuild is now in [testing]. Here is a rough ChangeLog:
kernel-headers: - upstream updated (2.6.29.1)
glibc: - update cvs snapshot from 2.9 branch - removed glibc-2.5-localedef_segfault-1.patch (old and appears fixed upstream) - removed glibc-2.7-bz4781.patch (rejected upstream as bug in gcc - Andy: please check if your issue is solved)
Afaik this was the patch to prevent full load with (gcj)java on x86_64 architecture. If openjdk6 is not affected I'm fine with dropping that patch.
- compress info pages - fix info page handling in install script
binutils: - update cvs snapshot from 2.19 branch - remove texinfo dep through install script - add upstream patch to improve -Wl,--as-needed usage - add linker scripts for libbfd.so and libopcodes.so - compress info pages
gcc-libs - new makedepends (ppl and cloog-ppl) - removed unneeded bison build patch - removed treelang (done upstream)
gcc - removals as in gcc-libs - added dependencies on new packages ppl and cloog-ppl (for graphite optimizations) - update libstdc++ man pages - install license exception - compress info pages
I am having great difficultly getting a working gcc-gcj... It builds fine using the gcc-gcj-4.3.x package but when I rebuild eclipse-ecj with the freshly built 4.4.0 package, I can not rebuild gcc-gcj again. Updating eclipse-ecj to the latest build does not fix the issue. After two and a half days of trying to track this down, I am ready to give up. If someone else wants to look at this, go ahead but...
Do we really need gcc-gcj, eclipse-ecj and java-gcj-compat any more? Reason I see for removing it: - I can't get it to build - java-gcj-compat provides java-runtime, but I checked six packages in the repos against this and none actually fully worked - which also is very bad as it is the first package found by pacman for java-runtime - we have a free java now in openjdk6
Opinions?
I'm fine with dropping gcj and compat pkg. Not sure if eclipse-ecj compiler is still needed to build other packages in extra that can't be build with other remaining packages.
Allan
GCC is broken. German website www.heise.de proved new gcc can't compile SPEC suite. See gcc main mailing list. They're working on a fix. Question: Is it safe to build regular packages except kernel/modules in testing with new toolchain and move them later to core/extra before the toolchain moves? -Andy
Andreas Radke wrote:
GCC is broken. German website www.heise.de proved new gcc can't compile SPEC suite. See gcc main mailing list. They're working on a fix.
Yeah, I have seen that. It is an x87 only bug so nothing too bad... (only a rated a P3 on the GCC tracker). I am keeping an eye out for the patch to be pushed.
Question: Is it safe to build regular packages except kernel/modules in testing with new toolchain and move them later to core/extra before the toolchain moves?
I built the kernel to test if the toolchain was good. I could still boot with the downgraded toolchain afterwards. So, it is likely to be safe. Allan
Am Sonntag, 26. April 2009 03:16:05 schrieb Allan McRae:
I built the kernel to test if the toolchain was good. I could still boot with the downgraded toolchain afterwards. So, it is likely to be safe.
I have build a kernel and KDE 4.2.3 without problems. Also linking with "- Wl,--no-undefined -Wl,--as-needed" no works ine with all packages. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Andreas Radke wrote:
Am Sat, 25 Apr 2009 21:15:08 +1000 schrieb Allan McRae <allan@archlinux.org>:
I am having great difficultly getting a working gcc-gcj... It builds fine using the gcc-gcj-4.3.x package but when I rebuild eclipse-ecj with the freshly built 4.4.0 package, I can not rebuild gcc-gcj again. Updating eclipse-ecj to the latest build does not fix the issue. After two and a half days of trying to track this down, I am ready to give up. If someone else wants to look at this, go ahead but...
Do we really need gcc-gcj, eclipse-ecj and java-gcj-compat any more? Reason I see for removing it: - I can't get it to build - java-gcj-compat provides java-runtime, but I checked six packages in the repos against this and none actually fully worked - which also is very bad as it is the first package found by pacman for java-runtime - we have a free java now in openjdk6
Opinions?
I'm fine with dropping gcj and compat pkg. Not sure if eclipse-ecj compiler is still needed to build other packages in extra that can't be build with other remaining packages.
So, looking into this further, apart from java-gcj-compat and eclipse-ecj, we have two packages that depend on gcc-gcj (gjdoc and jikes) and two that makedepend on java-gcj-compat (bcprov, juint - can probably be changed to openjdk6), but nothing else for eclipse-ecj. The apache-ant and openjdk6 PKGBUILDs both mention java-gcj-compat in a trivial way. So packages that would also need looked at to be removed when gcc-gcj, java-gcj-compat and eclipse-ecj go, are gjdoc and jikes. Jikes is a orphan and dead upstream as far as I can tell. It is also not needed given javac that comes with openjdk6. gjdoc is currently only a dep for java-gcj-compat. The only issue with packages in [community] is that classpath depends in jikes. Allan
participants (3)
-
Allan McRae
-
Andreas Radke
-
Pierre Schmitz