GCC 4.0

Message

robmoss · Post by **robmoss** » Fri May 21, 2004 7:14 pm

Ladies and Gentlemen... I've gone insane! Hurrah!

I've decided that, having fixed all outstanding issues I had with GCC 3.4.0, and considering that I was now using a "stable" (read: released) compiler for the first time in over a year, I was going to take the plunge and shift to GCC 3.5.

So, this is a call to arms. My overlay is located here:

http://home.jesus.ox.ac.uk/~rmoss/portage/local/

That contains all my GCC 3.4.0 fixes which haven't yet found their way into portage, and from now on will start containing GCC 3.5 fixes too. In particular, if you've ever emerged a package and seen something like "warning: use of cast expressions as lvalues is deprecated", that package now needs fixing! There's a fairly substantial list of packages which won't compile as yet, and CFLAGS should be kept very, very conservative indeed for now (mine are "-O1 -march=athlon-xp -fomit-frame-pointer -fprefetch-loop-arrays -pipe") or many things will segfault. But GCC 3.5 is really, really nice, and I believe that if we make the effort to port code now, not only will it benefit other packages but it will prevent the debacles that hit us with the releases of 3.3.0 and 3.4.0.

If anyone would like to help me in my efforts, please post back to this thread, and we'll see what we can arrange. Any help would be much appreciated.

Finally, a disclaimer: I am not responsible in any way for the breakage of your system, the sudden death of your favoured pet, the disappearance of your hardware out of the nearest window shortly followed by enraged screams, etc. etc. Expect things to break. This effort is reserved for the mildly insane only!

Current list of broken packages: audacity, dosemu, easytag, epiphany, festival, foomatic-db-engine, gdesklets-core, gnome-games, groff, grub, libggi, libmng, libsoup, mono, mozilla-firefox, mozilla, mplayer, nvidia-kernel, opensp, orange, svgalib, synce-gnomevfs, xine-lib (this may drop as I re-emerge with more conservative CFLAGS).

MOD EDIT: Made Sticky
--Deathwing00

spb · Post by **spb** » Fri May 21, 2004 7:38 pm

Just for confirmation, this is binary-compatible with 3.4, yes? I'm eager to give it a go, as long as I can use my firefox binary from 3.4.0. I don't think I'll try bootstrapping with it yet, though.

spb · Post by **spb** » Fri May 21, 2004 8:05 pm

Code: Select all

!!! Couldn't download gcc-3.5.0-piepatches-v8.7.4.tar.bz2. Aborting.

sobers_2002 · Post by **sobers_2002** » Fri May 21, 2004 8:20 pm

uh ppl excuse me for this ....but i am really in doubt abt what exactly is meant by things breaking up when gcc is upgraded..........i have 3.3.3 ......so if i upgrade to 3.5 i suppose it means some paching and all is gona be req....so pls enlighten me on the issue

spb · Post by **spb** » Fri May 21, 2004 8:23 pm

sobers_2002 wrote:uh ppl excuse me for this ....but i am really in doubt abt what exactly is meant by things breaking up when gcc is upgraded..........i have 3.3.3 ......so if i upgrade to 3.5 i suppose it means some paching and all is gona be req....so pls enlighten me on the issue

If you're not sure what's going to happen, don't upgrade. Seriously. Installing gcc 3.5 is almost certain breakage at the moment. As robmoss2k said,

This effort is reserved for the mildly insane only!

stonent · Post by **stonent** » Fri May 21, 2004 8:39 pm

I would say, if you haven't already made the plunge into 3.4 territory, then 3.5 isn't for you. 3.4 which works fine on my system, has been giving some people nightmares.

robmoss · Post by **robmoss** » Fri May 21, 2004 8:42 pm

thebell wrote:

Code: Select all

!!! Couldn't download gcc-3.5.0-piepatches-v8.7.4.tar.bz2. Aborting.

D'oh! Fixed. But I've managed to compile it, and now it doesn't compile here, which is weird. But I suspect I'm doing something stupid, let me know if it works for you...

GCC 3.5 is indeed binary compatible with 3.4.0 to all intents and purposes - just don't expect everything to go swimmingly

robmoss · Post by **robmoss** » Fri May 21, 2004 8:45 pm

sobers_2002 - if you have questions like that then I'm afraid 3.5 really isn't for you. This is an unbelievably unstable piece of software, particularly after the merge of the tree-ssa stuff a couple of weeks back (which is why I'm so interested in this) - and it requires a bit of black magic, a hell of a lot of luck and a seriously high level of knowledge of toolchain stuff to get this going at all. So I would say, don't do it. If and when I manage to get this to the stage where one can simply install this and expect it to work, then do it. But not before!

spb · Post by **spb** » Fri May 21, 2004 9:03 pm

Well, I commented out a few lines in the ebuild (the PIE_CORE= and PIE_BASE_URI= lines), and it compiled fine on a fresh stage2 tarball. We'll see how far it gets with system. Tomorrow though; no time tonight.

I was getting irritated with how well everything was working with 3.4.0, so this ought to provide a bit more interest, I'm hoping.

irf2003 · Post by **irf2003** » Fri May 21, 2004 9:07 pm

robmoss2k,
glad i found the gcc-3.5 thread, i was wondering where it may
be. just looking forward to all the fun / frustrations
we are going to have while gearing for gcc-3.5
keep up the good work
and happing gentooing

irf2003 · Post by **irf2003** » Fri May 21, 2004 9:18 pm

thebell wrote:Well, I commented out a few lines in the ebuild (the PIE_CORE= and PIE_BASE_URI= lines), and it compiled fine on a fresh stage2 tarball. We'll see how far it gets with system. Tomorrow though; no time tonight.

I was getting irritated with how well everything was working with 3.4.0, so this ought to provide a bit more interest, I'm hoping.

i concure with this PIE stuff tends to break things, let's
stick to plain vanilla gcc-3-bleeding-edge and check things out.
robmoss2k, i'm suprised you are on -O1, did -O2 -march
work for you?

UncleOwen · Post by **UncleOwen** » Fri May 21, 2004 9:36 pm

Now THAT sounds fun

robmoss · Post by **robmoss** » Fri May 21, 2004 11:27 pm

-O2 breaks many things with 3.5. -O1 is the only safe one - remember, there's been a MASSIVE CVS merge (the tree-ssa stuff, the ChangeLog size increased by about 7MB!) less than 2 weeks ago. -O2 is off limits for now.

Now, a warning, for everyone:

WARNING

Do not compile anything in your system profile with 3.5 yet. In particular, compiling binutils with 3.5 with any optimization level will kill it. It's possible to re-emerge with 3.4 no problem, but everything else will be dead. Things like bison, for example. So just don't do it!

In the meantime, I shall try to get everything else working fine first. 3.4 is just so boring, everything works

robmoss · Post by **robmoss** » Sat May 22, 2004 12:19 am

Right. I *think* it's binutils that's breaking. So my warning is basically: do NOT compile binutils with GCC 3.5. It will (probably) kill everything!

I'm going to make a proper CVS ebuild and make it recompile GCC as part of my system update script. I know, I know, CVS compilers are a bad idea, you should check that the tarball passes the bootstrap test, yadda yadda yadda - I don't care, I consider the latest fixes to be more important. I'll call this one gcc-3.5.99, mask it if you need to using /etc/portage/package.mask.

ecatmur · Post by **ecatmur** » Sat May 22, 2004 12:48 am

Shouldn't that be 3.4.99? Or sth like 3.5.0_pre20040422?

GentooBox · Post by **GentooBox** » Sat May 22, 2004 1:33 am

robmoss2k wrote:Right. I *think* it's binutils that's breaking. So my warning is basically: do NOT compile binutils with GCC 3.5. It will (probably) kill everything!

I'm going to make a proper CVS ebuild and make it recompile GCC as part of my system update script. I know, I know, CVS compilers are a bad idea, you should check that the tarball passes the bootstrap test, yadda yadda yadda - I don't care, I consider the latest fixes to be more important. I'll call this one gcc-3.5.99, mask it if you need to using /etc/portage/package.mask.

You are insane.

You hunger after a broken system.

Thats why i synced my portage overlay with yours

robmoss · Post by **robmoss** » Sat May 22, 2004 1:41 am

ecatmur wrote:Shouldn't that be 3.4.99? Or sth like 3.5.0_pre20040422?

No, because the current snapshot is named 3.5.0 (for gcc-config reasons) and as the CVS is newer it should be 3.5.99 to avoid any difficulties. I would like to call it 3.4.99, but gcc-config would most certainly whinge...

Lv · Post by Lv » Sat May 22, 2004 5:36 am

i have a gcc 3.5 cvs ebuild up at http://dev.gentoo.org/~lv/gcc-3.5.0.ebuild to aid porting efforts. each merge should give you the most up-to-date version of mainline.

you people are nuts, but i love ya anyways

*gets back to making sure people have a proper migration path to gcc 3.4, which is not at all perfect yet*

NOTE: that ebuild is old and semi-broken, now that i look at it. you defiantely want to remove the gcc_compat crap from it... you might want to sync up any non-cvs parts with the latest gcc 3.4 ebuild.

spb · Post by **spb** » Sat May 22, 2004 9:15 am

robmoss2k wrote:No, because the current snapshot is named 3.5.0 (for gcc-config reasons)

Just FYI, I renamed my copy of the snapshot ebuild to 3.5.0_pre20040516, and gcc-config works fine (just names it 3.5.0).

PrakashP · Post by **PrakashP** » Sat May 22, 2004 10:51 am

I thought about trying to build stuff from a stage2 as well, to which I chroot from my normal installation.

Could anyone explain me (is it possible?) how to easily sync to robmoss2k overlay? I know portage 2.0.5 can have multiple overlays, but I dunno how. I just have my "personal" overlay. Beside that I would like to have robmoss2k's one. It would be nice if someone could point me to the right direction.

robmoss · Post by **robmoss** » Sat May 22, 2004 11:11 am

Lv wrote:*gets back to making sure people have a proper migration path to gcc 3.4, which is not at all perfect yet*

Lv, what's broken? The OpenOffice stuff is beyond me, as is the sun-jdk stuff, as I'm not well-versed enough in C++ to port those without them breaking. But if you can point me in the direction of something else that's knackered I'd be happy to have a go at it...

robmoss · Post by **robmoss** » Sat May 22, 2004 11:24 am

PrakashKC wrote:I thought about trying to build stuff from a stage2 as well, to which I chroot from my normal installation.

Could anyone explain me (is it possible?) how to easily sync to robmoss2k overlay? I know portage 2.0.5 can have multiple overlays, but I dunno how. I just have my "personal" overlay. Beside that I would like to have robmoss2k's one. It would be nice if someone could point me to the right direction.

Someone has an rsync mirror of it somewhere, but unfortunately I can't manage any better than HTTP (not my decision, it's my college's). So, if you put your overlay in /usr/local/portage/prakashkc, and make a directory called /usr/local/portage/robmoss2k, and then change the line in /etc/make.conf to "PORTDIR_OVERLAY="/usr/local/portage/robmoss2k /usr/local/portage/prakashkc" (they're checked in reverse order, so it will find your ebuilds before mine), then all you have to do to sync with my overlay is download http://home.jesus.ox.ac.uk/~rmoss/porta ... -local.bz2, move all the files from /usr/local/portage/robmoss2k/local/ to /usr/local/portage/robmoss2k/, remove the "local" directory (yes, that is a bug with the tarball generation, I'll fix it soon), and watch it all happen!

Or, should I say, watch it all happen

PrakashP · Post by **PrakashP** » Sat May 22, 2004 12:52 pm

Thnx, I will try it ASAP.

(later) So the basics are done, lets compile gcc-3.5.

Lv · Post by Lv » Sat May 22, 2004 1:17 pm

robmoss2k wrote:
Lv wrote:*gets back to making sure people have a proper migration path to gcc 3.4, which is not at all perfect yet*
Lv, what's broken? The OpenOffice stuff is beyond me, as is the sun-jdk stuff, as I'm not well-versed enough in C++ to port those without them breaking. But if you can point me in the direction of something else that's knackered I'd be happy to have a go at it...

SSP in any glibc version other than 2.3.3_20040420-r1

you should be able to do the following:

Code: Select all

lv@ayanami lv $ readelf -s /lib/libc.so.6 | grep guard
   655: 0000000000205e48     8 OBJECT  GLOBAL DEFAULT   31 __guard@@GLIBC_2.3.2
   810: 000000000001d060   159 FUNC    GLOBAL DEFAULT   11 __guard_setup@@GLIBC_2.3.2

however, with any other version than that, gcc 3.4 nukes those symbols. but i cant just have all archs use 2.3.3_20040420-r1... not only is the ssp in it experimental/iffy, it wont even compile on ppc64 (and possibly elsewhere). i attempted to get the symbols to stay by marking them with the used and default visibility attributes, but gcc 3.4 is bein a ho.

also, i need to figure out and implement a proper migration path. i posted the libstdc++ ebuild to the 3.4 thread, and i'm thinking of masking gcc 3.4 in all profiles and making a new profile for gcc 3.4 (in order to force install libstdc++ on any arch that actually needs it without making gcc and/or all binary packages depend on it). BUT... gcc 3.3.3 also provides the same libstdc++. how do i handle conflicts? i cant make a profile depend on it and then make libstdc++ conflict with gcc 3.3.3.... you might still want the older gcc around.

plus, i need to be very sure about the gcc 3.4 ebuild itself before marking it as testing... oh yeah, and the second i do there will most certainly be a flood of bug reports about stuff i missed. i'm not looking forward to that, as i pretty much seem to be the only person working on gcc 3.4. the rest of toolchain flat out refuse to touch it, mostly because they're also hardened devs and are still working on getting gcc 3.3.3-r5 perfect. r5 wont even compile on alpha, and probably mishandles PIE on an arch ir two (works perfectly on x86, amd64, and sparc though).

ummmm...... i dunno, but i think just fixing the guard symbol stuff is enough to get 3.4 into testing on ppc64 and mips. add in libstdc++ compat crap and you can add amd64 to that list. the flood of bug reports that will eventually come makes me uneasy about pushing it to x86... admittedly, 3.4 isnt really needed on x86. however, on amd64 kernel 2.6.6 and later miscompile without it. on ppc64 damn near anything will be broken without it, they're currently using the hammer branch of 3.3.3 to get arch related fixes (go fig, eh?). on the mips O2 port (i think, i may be wrong here), you need to use gcc 3.4 or c++ just isnt an option for you... etc

EDIT: oh yeah, and uclibc support is almost non-existant and surely broken at this point... i should probably fix that too eventually.

Tii · Post by **Tii** » Sat May 22, 2004 1:59 pm

robmoss2k wrote:This is an unbelievably unstable piece of software, particularly after the merge of the tree-ssa stuff a couple of weeks back (which is why I'm so interested in this) - and it requires a bit of black magic, a hell of a lot of luck and a seriously high level of knowledge of toolchain stuff to get this going at all.

So if one wanted to learn a bit more about this stuff where would one start (I'm a curious creature hopefully with years to learn new things)?