Missing ebuild for new GCC v3.4 Reproducible: Always Steps to Reproduce: 1. 2. 3.
As of 4/20/2004, gcc 3.4.0 has been released - the tarballs are propagating to the mirrors, but are already available on ftp://gcc.gnu.org/ aka ftp://sources.redhat.com/. I've succesfully bootstrapped this on an athlon-xp Gentoo 2004.0 system, and it passes the greatly enhanced testsuite. I believe the c++ ABI is incompatible with gcc-3.[23], so it probably needs a new SLOT, but it successfully builds the 2.6.6-rc1-mm1 kernel, and seems to work so far.
Alex, have you made an ebuild for this? If not I'll make one.
Created attachment 29778 [details] gcc-3.4.0.ebuild Okay people, here it is in all its shiny goodness... the ebuild for GCC 3.4.0! Hurah! Currently compiling, but no errors so far. I'll report back on what I find out.
Created attachment 29779 [details, diff] gcc-3.4.0-gentoo-branding.patch Put this in ${PORTDIR_OVERLAY}/sys-devel/gcc/files/3.4.0/ and all will be well - and Gentoo branded :-)
we are waiting on the propolice patches which is why we havent added 3.4.0 yet, just the pre release
Fair enough. My shiny new GCC 3.4.0 installation is wonderful, it goes like shit off a shovel...
This line should be changed from: SRC_URI="ftp://gcc.gnu.org/pub/gcc/releases/${P}.tar.bz2 to: SRC_URI="ftp://gcc.gnu.org/pub/gcc/releases/${P}/${P}.tar.bz2 ;)
Created attachment 29810 [details] gcc-3.4.0.ebuild Whoops, sorry - fixed above...
Still waiting on one gcc extention. (next few days hopefully) http://www.trl.ibm.com/projects/security/ssp/ After the extension is ready/released the 3.4.0.ebuild will have to be rewritten because 3.3.3-r2 is still in active development. Till then it's best to keep on pecking away on Bug 48528 depends.
I tried to bootstrap using this ebuild. It didn't work, here's the error I got: echo timestamp > gcc.pod perl /var/tmp/portage/gcc-3.4.0/work/gcc-3.4.0/gcc/../contrib/texi2pod.pl /var/tmp/portage/gcc-3.4.0/work/gcc-3.4.0/gcc/doc/invoke.texi > gcc.pod /bin/sh: line 1: perl: command not found make[1]: [gcc.pod] Error 127 (ignored) echo timestamp > doc/gcc.1 /bin/sh: line 1: doc/gcc.1: No such file or directory make[1]: *** [doc/gcc.1] Error 1 rm gcc.pod make[1]: Leaving directory `/var/tmp/portage/gcc-3.4.0/work/build/gcc' make: *** [install-gcc] Error 2 as you see, it tries to use perl for something, which of course isn't aviable during bootstrap. I checked that doc directory and it was empty so I tried to unpack the gcc-3.4 tarball somewhere else and copy the files that are supposed to be in there. It didn't work, I got the same error message, and after the doc dir was empty again.
Andreas, I can't say I've even *tried* myself to bootstrap using 3.4.0. I think it would need perl adding to the stage1 tarball for that to work and a perl dependency being added to GCC? I've never worked on bootstrap.sh to be honest, so I'm guessing a bit. However, solar is right, the 3.4.0 ebuild *will* have to be completely rewritten once the last extension is rewritten - the above error being a case in point. Since I started using 3.4 in January I've not *once* managed to bootstrap with it - but then, I only tried once... Anyway, I have a few more 3.4-related bugfixes on the way, when "emerge -e world" finishes I'll post my remaining fixes.
well.. its only a 11k perl script. I was thinking that maybe it could be converted to something that is aviable during bootstrap, like a bash script, or maybe python. It seems a bit overkill to add perl just for a 11k script. But I don't know..
the perl stuff generates man pages. the 3.3 ebuilds take care of this by providing pre-generated man pages. so will 3.4 when it's ready... which it certainly isn't at the moment. i wouldn't recommend doing a bootstrap with it yet. there also seems to be an additional problem on archs with bi-arch toolchains where libgcc_s from 3.3.x is still being used instead of the 3.4 version... and other stuff. gcc 3.4 will remain masked -* for quite some time yet.
I believed the c++ ABI now conforms to some kind of standard, which is also used by ICC. any sources for a incompatible c++ ABI between 3.3 <> 3.4 ?
the abi is incompatible on mips, and i think one other arch. either way there is the incompatible version of libstdc++ to deal with. c++ apps compiled with gcc 3.3.x will still need it around in order to work, or we need to create another compatibility library to ease migration.
i've committed a new gcc 3.4.0 ebuild. it's not this one, but it could still use some testing. i'll keep this bug open as it seems to be functioning as a gcc 3.4 meta-bug for some reason... i'd like to note that gcc 3.4.0 is still masked and it'll be some time before it even makes it's way into testing
well for what it's worth the 3.4.0.ebuild as of now doesn't even build on ppc64, I'll try and investigate a bit more.... The 3.4 prelease that WAS in portage actually did build and work just fine. If the pre was there stil I could at least compare to see what changed ;-)
it's been added to portage now
*** Bug 51934 has been marked as a duplicate of this bug. ***