GCC 3.4.3 is upon us!

[Jengu]

[Jengu]

Ack, now neverball has messed up fonts. irf, those compiler flags are definitely not entirely stable

[kezzla]

Any suggested USE flags for gcc 3.4.3 using amd64 (32-bit) ?

[irf2003]

[agnitio]

I would like to start with thanking everyone in this thread, it has been so very helpful. Although I do have one question. After reading here I got the feeling that one shouldn't include sse2 and such in the CHOST optimization-flags, is this correct. If that is the case, then I suppose mine shouldn't look like this?

[geki]

at the time of gcc 3.4.1/2 -msse2 code was horrible broken in gcc. because of that lv made gcc automagically add -mno-sse2 (invisible at compile-time). but if you add -msse2 it was activated and _could_ cause broken installs.

I do _not_ know how it is right now but if that sse2 code gets well again i guess lv would drop that workaround.

As I know -march=pentium4 adds -msse2 as well but would not break lv's workaround.

Anyone may correct me please, thanks!
_________________
hear hear

[agnitio]

Thanks alot. That really cleared things up. So I suppose I'll remove the -msse2 and just rely on the -march=pentium4 flag.

[jedsen]

Damnit. I just emerge 3.4.1 last night.

[geki]

[tleavitt]

I noticed 3.4.3 out and I tried to emerge on my amd64. It would appear that it went on building fine until it hit what would appear to be the multilib portion of the compile. Got an error that I wasn't quite expecting. I'm running a 2.6.9 kernel and have 32-bit compatability libraries installed. I currently have gccgcc-3.3.4-r1 running and compiled w/ multilib. Sorta' curious what's happening here being an ametuer.

Tried to build w/ USE flags: fortran, gtk, multilib, nls... nothing too unusal here

[Satori80]

[irf2003]

[Deranger]

[Satori80]

I must be missing something... are there packages in not in system that are used to comple other packages?

[Jengu]

For the record: The neverball font problem was due to a change in my xorg.conf I forgot about, not compiler flags.

Also, the gaim problem was solved by unmerging arts. Since I didn't have this problem before, I'm guessing that arts doesn't like one or more of those compiler flags.

Since I don't use kde or arts anyway I just put -arts in my use flags.

[oberyno]

Gotta say, I agree with Satori80 here. Let's take openssl as an example.

First I emerge -e system. That gives be a system with a decent toolchain, but that might have strange bugs due to being compiled with a broken toolchain. Thus I emerge -e system again.
Next I emerge -e world. Afaict, emerge -e world emerges in dependency order, so nothing that depends on openssl will get built before openssl. So, openssl gets compiled with a clean toolchain, then python gets built against the new openssl, etc...

Maybe I'm missing something, but I just don't see how 2 emerge -e world's will help.

[sakarns]

I seem to be having the same problem emerging gcc as reported by tleavitt. This is happening on a dual processor amd64, nothing special in my USE flags.

[Petyr]

[Lokheed]

I agree Petyr. I have always been confused about the lengthy process.

Realistically I cant see doing more then emerge -e system && emerge -e world.

The first will compile your system and the world will compile your system against the toolchain along with packages in your world...

The world emerge does everything in system again so that takes care of 2 systems and you only need 1 world because packages are compiled in order. This means all packages outside of system will be compiled against the system toolchain and against the world toolchain as they go down in the list.

I find the 4 emerges to be extremely overkill without it making much sense.

[Deranger]

[Satori80]

[robmoss]

There are two important points to note. The first is that anything in the toolchain will almost certainly have a dependency set which is fairly incorrect and very incomplete. The reason for this is simple: if it is correct and complete, bootstrap doesn't work, and emerge can't work out a package order for pretty much anything (try it).

The second important point is that linking against a programme compiled using one toolchain, and then remerging the package you linked against with the new toolchain, is not necessarily consistently well-behaved unless the dependencies are correct and complete (which again won't work) and have not changed (which doesn't always hold).

And another point to note, I suppose, is that the standard GCC build involves three full compiles - so you build 3.4 with 3.3, then you build 3.4 with your new 3.4, then you build 3.4 with the 3.4-built 3.4 to check that it works, and you use that one because it's the cleanest compiler (again, try it).

Compilers are a black art. If something makes sense, it's probably wrong.
_________________
Reality is for those who can't face Science Fiction.

emerge -U will kill your Gentoo
ecatmur, Lord of Portage Bash Scripts

[rhill]

[Satori80]

, good point.

BTW, I find a few packages that won't compile against gcc version 3.4.3 20041125. Is there a thread to report to for this or is it appropriate to file bug reports on ~x86 packages? I hesitate to do the latter simply because I wouldn't know if the issue is with GCC or the packages – or even the ebuilds for the packages that are failing on the new compiler.

[Lokheed]