This bug will be used to track all packages that must be stabilized before GCC 4.5. I'm not planning on working on this for a couple months but if anyone wants to get started, go nuts. - Please file a NEW bug for each package that needs to be stabilized and have it BLOCK this one. - The bug should be assigned to the maintainer of the package. Please do not CC gcc-porting - we get enough mail on these things. - DO NOT use this bug for any problems with GCC itself. Instead, file a NEW bug describing your issue and it will be assigned by a bug wrangler. Thanks.
It looks bug #347782 is still valid, i can't reopen them. Should i create new bug? gcc-4.5.2 on hardened gives PAX: terminating task: /usr/sbin/apache2(apache2)
Team, the only open bugs left here are ones that no one cares about* or have multiple depending bugs that no one cares about. Let's make progress and move forward with the stabilization of gcc-4.5 (trickle effects are that new mozilla products can be stabilized, which is more of a win for our users than these random packages imo). So, any thoughts or should I just mask the offending packages? *My opinion, from reading the bugs.
- bug 331181 -> a comments thinks bug 350059 should block that stabilization, but looks like it's not a regression over current stable (2.12.2) and, then, shouldn't block that. - bug 360597 -> looks like -r1 can be stabilized - bug 360601 -> bug 301625 contains a patch that should fix it, about bug 333877 it doesn't seem a regression and, then, shouldn't block stabilization
(In reply to comment #3) > - bug 331181 -> a comments thinks bug 350059 should block that stabilization, > but looks like it's not a regression over current stable (2.12.2) and, then, > shouldn't block that. > - bug 360597 -> looks like -r1 can be stabilized > - bug 360601 -> bug 301625 contains a patch that should fix it, about bug > 333877 it doesn't seem a regression and, then, shouldn't block stabilization Nice analysis, now arch teams are called on all the remaining packages. If they find problems, we will drop the stable keywords on them. @toolchain: Please nail down a specific gcc version and push this forward by calling arch teams, thanks!
let's roll with 4.5.3-r1 if no one has any new complaints
Emerged @system ~450 packages no problem, and emerge world ~700 packages on other machine. amd64 ok ( the bug depends on are already confirmed)
+ 20 Sep 2011; Tony Vroon <chainsaw@gentoo.org> gcc-4.5.3-r1.ebuild: + Marked stable on AMD64 based on arch testing by Agostino "ago" Sarubbo in bug + #357479.
Should GCC 4.5 be archtested even though there are 3 depends on this bug?
yes. those maintainers might move faster if gcc-4.5 were in stable. or they might not in which case we have packages to tree clean.
Archtested on x86 (i686): GCC tests failed, but emerge succeeded (only emerged GCC once with 4.4.5 and once with 4.5.3) and system rebuild succeeded (226 packages).
I get C++ preprocessor sanity check errors here on x86. Need to investigate this a bit.
ppc/ppc64 stable
(In reply to comment #11) > I get C++ preprocessor sanity check errors here on x86. Need to investigate > this a bit. I've seen no problems like that here. Could you post the actual error messages? I've upgraded to gcc-4.5 on my stable x86 machine, rebuilt world, etc. I plan to soon mark it stable after looking at the bug dependencies.
x86 stable, thanks JD and Myckel
I've hit bug #379421 and bug #384739 with gcc-4.5 stabilisation. That breaks both vmware and virtualbox virtual software (with ~10 other OS images) for me. I would really appreciate if someone could help to verify virtualbox patch and fix vmware.
Stable for HPPA.
arm stable
alpha/ia64/s390/sh/sparc stable
Only m68k missing here.
I'm running into an issue here with this stablization, and could use some guidance into how exactly to file the bug. The easiest way to reproduce it is to grab the latest stage3 for ARM, (at the time of this writing, it's stage3-armv7a_hardfp-20120730.tar.bz2 ) - do the normal chroot fun times, and then emerge gcc - what I am seeing happen here is that it compiles just fine, fails during postrm: <<< dir /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.5.3 <<< dir /usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.5.3 [sys-devel/gcc-4.5.3-r2] bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory This issue occurs on my MX6 board using SATA. blueness: the build.log can be found on hardenedmx6 in /chroots/neon/var/tmp/portage/sys-devel/gcc-4.5.4/temp This is the second time I've seen this occur, and the first time was in a softfp chroot, so I don't think it's hardfp specific.
(In reply to comment #20) > I'm running into an issue here with this stablization, and could use some > guidance into how exactly to file the bug. The easiest way to reproduce it > is to grab the latest stage3 for ARM, (at the time of this writing, it's > stage3-armv7a_hardfp-20120730.tar.bz2 ) - do the normal chroot fun times, > and then emerge gcc - what I am seeing happen here is that it compiles just > fine, fails during postrm: > > <<< dir /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.5.3 > <<< dir /usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.5.3 > [sys-devel/gcc-4.5.3-r2] bash: error while loading shared libraries: > libgcc_s.so.1: cannot open shared object file: No such file or directory > > This issue occurs on my MX6 board using SATA. > > blueness: the build.log can be found on hardenedmx6 in > /chroots/neon/var/tmp/portage/sys-devel/gcc-4.5.4/temp > > This is the second time I've seen this occur, and the first time was in a > softfp chroot, so I don't think it's hardfp specific. steev has this running on a board that I also have access too. I looked at it and the problem is that /etc/ld.so.conf.d/05gcc-armv7a-hardfloat-linux-gnueabi.conf has /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.5.3 instead of /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.5.4 So the ld.so cache is looking in the wrong place for libgcc_s.so.1. The fix is to add the last line to 05gcc-armv7a-hardfloat-linux-gnueabi.conf and then in the root of the chroot do chroot . /sbin/ldconfig You should then be fine. (This probalby should have been in a separate bug report.)
Done.
