EDIT2: The virtualbox issue might be just some Makefile.kmk trouble with the gcc version detection_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

A few gcc-4.7 questions.
What versions of glibc are you all using?
I am not sure it it is better to stay with stable everything or go keyword?

Were you able to build dev-lang/perl-5.16 ?

I noticed in the bug reports that people are not enabling the -flto in cflags it seems this needs to be enabled in the cflags for the new feature to be used.

I couldn't build dev-lang/perl-5.16.1 with 4.7.2 (with or without lto) Along with a bunch of other stuff, in fact after finishing @system I had a handful of things that wouldn't build at all then I couldn't use any commands at all, luckily I did an rsync before giving that gcc version a spin. I'm not sure if it was something on my side though since many are able to build everything just fine. Running ~amd64 - sys-libs/glibc-2.15-r3.

It is interesting what builds and what doesn't
I am using:
[2] i686-pc-linux-gnu-4.6.3
[3] i686-pc-linux-gnu-4.7.1 *
So far I cant get Perl to build.
I got most of my minimal system to build with it though.
I have not run in to problems mixing stuff from the above 2 versions.
Interestingly I got Firefox 15 to build (10 wont) and have noticed a improvement in a long standing annoyance loading really long huge html pages. It could just be the version bump in firefox though.

EDIT: (I am on -r2 and more stable stuff than keyworded however I always keyword perl)_________________Donate to Gentoo

Yep, perl-5.16.1 did just fine again with the following USE flags: "doc gdbm -berkdb -debug -ithreads"

@turtles: You will likely stumble upon some stable packages that fail to build with gcc-4.7.2. I would put those into p.keywords with an increased version number.

One or two world packages that were to be emerged after the gcc-4.7.2 switch were not covered by the tracker bug yet, one of them gnash, it still needs a patch that can be found in bugs.gentoo.org._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

@turtles
I must apologise for giving you misleading information due to a silly mistake on my part
After posting I was searching and found: https://forums.gentoo.org/viewtopic-t-927252-start-0.html - I completely overlooked this.
dev-lang/perl-5.16.1 will build for me now, but not with lto. I guess now it's time for round two

I didn't have any new ones in my package.env then mentioned on that blog afiak, I completely forgot I had added things to the package.env before rebuilding the second or third time
Anyway, a few days later I noticed some auto-mounting wasn't working right and a few programs were also really slow to start up, constantly, so I rolled back to the backup I made before trying lto and just stopped messing with it.

Since then though I had a huge system slimdown getting rid of *kit's and udisks and all that stuff, I'm planning on trying an lto rebuild of the system when gcc 4.8 is beta in the toolchain overlay.
Also, I must say that the lto experience was a lot less painful then the compiling the system with clang experience.

Also, I must say that the lto experience was a lot less painful then the compiling the system with clang experience.

The main disadvantage of clang is that lto is a lot worse!
To have an example, compile eix with gcc and with clang, both with and without lto: while gcc+lto reduces the binary by a factor 2-3, clang+lto has almost no effect on the produced size (which is about as bad as gcc without lto).

Also, I must say that the lto experience was a lot less painful then the compiling the system with clang experience.

The main disadvantage of clang is that lto is a lot worse!
To have an example, compile eix with gcc and with clang, both with and without lto: while gcc+lto reduces the binary by a factor 2-3, clang+lto has almost no effect on the produced size (which is about as bad as gcc without lto).

Interesting, I had a similar results when compiling a couple of games whilst just seeing if they would build with clang, I didn't compare any system binaries though.
Also, march=native with clang can really screw up apparently, chromium built fine then refused to run because of illegal hardware instructions and after some googling it seems clang with march=native is an issue sometimes, after 20 mins in elinks I just went for a rollback, who knows what else may have been broken.

Id say my system is stable and noticably faster.
google-chrome and then firefox more stable and faster after I did -lto
and gcc 4.7.1
I am not going to push it with 4.7.2
also:

net-p2p/qbittorrent-3.0.6 is the lowest version that builds with 4.7 -lto

rorgoroth lots of us are interested in making of all the kit stuff optional. keep us posted.
I would be interested in helping make a wiki or install guide for that. however the wiki hates me when ever I try to write something I break too many wiki rules...
I compiled a interesting tool from puppy linux called pup-volume-manager.
I was considering porting it more completely to Gentoo with an ebuild but I am not sure what it should block.
I have mostly been using udisks-glue with my various openbox / JWM setups._________________Donate to Gentoo

rorgoroth lots of us are interested in making of all the kit stuff optional. keep us posted.
I would be interested in helping make a wiki or install guide for that. however the wiki hates me when ever I try to write something I break too many wiki rules...
I compiled a interesting tool from puppy linux called pup-volume-manager.
I was considering porting it more completely to Gentoo with an ebuild but I am not sure what it should block.
I have mostly been using udisks-glue with my various openbox / JWM setups.

I think the main way is choice of applications, and of course globally disabling polkit and consolekit, what caught me out is that I had installed by accident consolekit to world, took maybe 2 hours trying to fix a circular dependency between consolekit, polkit and pambase before realizing my stupidity and just -C'ing consolekit and then full update fixed everything up. Take a look at https://forums.gentoo.org/viewtopic-p-7191396.html for some specifics people have worked through.
I completely got rid of anything udisk related and use pmount in combination with spacefm (file manager) and it works very nice in terms of auto-mounting, syncing, removing, ejecting, etc etc.

You lot are making me really curious about -lto. Having installed 4.7.2 already and no other issues left... Unfortunately, gold seems to break a lot of things, so I'm not sure one should switch to it at the same time as -lto._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

You lot are making me really curious about -lto. Having installed 4.7.2 already and no other issues left... Unfortunately, gold seems to break a lot of things, so I'm not sure one should switch to it at the same time as -lto.

On the gold topic, what has broken? I think I read about a couple of oddities some time ago but my whole system and world was rebuilt a few weeks ago (graphite curiosity/testing) and nothing failed or broke, if something does fail or break then the makefile needs to be fixed afiak.

The thread got me wondering about lto again too, I had @system rebuilt last with lto (forgot to set it to build world after, woke up earlier and kicked myself), going to set @world going in a few mins.

Five open bugs listed there are showstoppers for me. Given there is not a lot of testing going on with gold, I suppose there will be many more failing packages out there. Probably it's best to try out in a VM or wait for flameeyes to set up a gold tinderbox again. And if, I would first go with -lto to see what breaks, then try with gold. Unless the scenario's the other way round, with -lto having a better chance to work with gold._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

For clang+lto it is not a question: You have to use gold, otherwise it will not work.
For gcc, I use bfd. I had some issues when tryig gold as system linker, but I forgot what it was. I think that I was just overcareful and reverted at the first problem.

Quote:

GCC guys seem to recommend using the gold linker

The main difference is that if you do not use gold then static libraries (.a) are linked without being "recompiled", i.e. you do not obtain all theoretically possible advantages of lto for projects which use static archives in their build system.

Here is my list of files not working with lto. Maybe some of the projects are fixed meanwhile, but I guess most not. The reason to put firefox and libreoffice in this list was compile time IIRC.

Thanks for the info guys
Anyway, on the Firefox and Libreoffice front, I cannot get Firefox to build with lto, nor am I able to compile Libreoffice (4.0.0.1) with lto, BUT...

During configure stage of Libreoffice:

Code:

checking whether to use link-time optimization... no

So I set up an extra env and specified:

Code:

EXTRA_ECONF="--enable-lto"

Which then gave me:

Code:

checking whether to use link-time optimization... yes

So it should build (I let it run for an hour without failure while I was cooking whereas it failed within 30 minutes before), I am going to do it tonight since it takes ~5 hours to build anyway, I know the devs don't want LTO bugs but do any of you think it's worth requesting an (masked) lto use flag? Would a bug report be appropriate? Email to the maintainer?

No idea really - coincidentally, I've got an other problem since firefox-17: It won't build with gcc-4.7.2 and custom-cflags, which I know is unsupported, but still... even without any fancy stuff, and -16 was ok. Has anyone in here had the same trouble?

Of course with -fno-lto passed via env.
There are some results on google about your error for 4.7.2 + graphite + firefox 17 although I have no real idea, it's either firefox 17 or ppl as far as I can tell from a quick read. I'm using ppl 0.12.1-r1 in case that is of any interest.

I can stop then to find the relevant flag. At least that way I found out that profile-guided optimisation was masked - I re-enabled it and set up env for firefox with safe flags._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic