I'm playing around with GCC 4.5. From toolchain.eclass: if [[ -n ${SNAPSHOT} || -n ${PRERELEASE} ]] ; then echo ${PV/_/-} > "${S}"/gcc/BASE-VER echo "" > "${S}"/gcc/DATESTAMP fi DATESTAMP is made available by gcc in the form of the __GLIBCXX__ macro. When it is empty, valid (as in "meant to be accepted by vanilla GCC") code in the form of #include <bits/c++config.h> #if __GLIBCXX__ >= 20090101 yay! #else #error boo! #endif fails to pass the preprocessor. This happens with www-client/chromium. I'm not sure why DATESTAMP is getting cleared, but could you either keep the existing date, or change it in a way that's less likely to break code? (Actually, chromium triggers a different error earlier, but that's something not caused by Gentoo, which I'll report upstream once I figure out where to send it.)
i was hitting this with webkit-gtk with the svn ebuilds because i was overriding DATESTAMP in the ebuild. didn't realize the eclass does it too.
the DATESTAMP logic you quote dates back to when we were shipping snapshotted releases (i.e. the bumpy 3.3 and 3.4 days). changing the logic to only support real snapshots is fine by me as i have no plans to go back to those days.
What exactly would that mean? It's already covered by a check for gcc 4.1+ so it won't affect anything older anyway; simply remove the echo "" line, then? This gives the right result after installation, but maybe you were thinking of something slightly different.
i havent built the snapshots from the toolchain overlay in a while. apparently you have, so i'd ask you what is needed to make the snapshot ebuilds do what you expect. i also vaguely recall that the DATESTAMP is used in naming paths/binaries, so you'll have to make sure that part isnt screwed either with gcc-config and installation.
The gcc 4.5 (4.5.0_alpha20091210) I've got is built and installed correctly and functions properly with gcc-config with only the DATESTAMP line removed from the eclass. There is some minor redundancy in the --version output: gcc (Gentoo 4.5.0_alpha20091210) 4.5.0-alpha20091210 20091210 (experimental) but that's not actually a problem, and all the paths and executable names are correct as far as I've seen (I saw no changes when rebuilding 4.5-20091203 with the modified eclass), so I'll go ahead and commit this then, later today, thanks. I think you're thinking of the BASE-VER on the line above, which is suspiciously similar to the suffix on several executable and directory names, so I'll make sure to leave that alone.
if you've tested it (and it looks like you have), then feel free to commit. thanks.
Done.
