So, finally Mark gave us GCC 4.5.0 to play with in the tree… obviously it’s still masked, as the tree is definitely not tested to work with it. But this is why I’m working on the tinderbox, isn’t it? After the ebuild was there, I prepared to start a new run from scratch to the tinderbox. What is a “new run from scratch”?
Well, the tinderbox usually works incrementally: not only it has a queue of packages to merge, but every time I sync, it resumes (more or less) from where it stopped. When the whole queue is consumed, a new list is generated of packages that haven’t been merged in the past six weeks, or that have been merged but have new versions (or revisions) in the tree, and that becomes the new queue.
A new from scratch run means that the tinderbox is cleared out: all the packages that are not part of the tree induced by the world and system sets are removed by the tinderbox, system and world are rebuilt, then a new list of all the rest of the packages… then it starts. It might sound easy and quick, but to unmerge 12000 packages (yes, twelve thousands!) it takes well over a day.
This by itself is a good test for unmerge actions, and it provides useful clues. For instance I know that a single unmerge of a bunch of texlive modules will take æons to complete, as it rebuilds the font cache after every unmerge. The same is true for the packages that update the MIME database, and to a lesser extent to Python modules. Having a way to deal with these things at once at the end would most likely help us here.
Now, I originally wanted to go on and implement the spec file trickery to check for flags (remember? this was one of the first reasons why I started working on the tinderbox), but at the end, I decided to leave that for another time. My reason for not going with that at the same time as GCC 4.5 is that… this time I’m going to get surprised: I sincerely have no idea which problems this GCC will produce, compared to the problems that could have been caused by GCC 4.4 which I had a good clue how to fix before starting.
Also, I’ve been pretty scared to the effects of GCC 4.5 on my host system: during the rebuild, GNU tar stopped working properly, so that, for instance, all the calls to libtoolize within the ebuilds failed as they weren’t able to update the config.sub and config.guess files. I worked this around in the middle of the merge by switching tar with bsdtar provided by libarchive, and all is working fine, for now. The tar failure has to get investigated though, obviously.
Anyway, the work has started, even though it’ll take a bit to roll out entirely — I hope you’ll enjoy the results. And if you feel like thanking me, there is the wishlist — too bad that I can’t put eBooks in that list (since I don’t use a Kindle).
Gcc is fine, but don’t you think it would be about time to try Open64 ?Folks report serious speedups ( which I couldn’t corroborate in simple apps like bzip2 BTW), but compiler has some snags.One is, it compiles itself correctly only as a 32-bit binary, but it can produce 32-bit as well as 64-bit code…One can emerge it ( or compile by hand), but it is not used by portage, nor can it be gcc-config’ed.It would be nice to see how it behaves on the whole system…
Given that the gcc 4.5.0 is in portage is it time to send bugs without patches? I don’t see any I_PROMISE in ebuild so I think so but I prefere to double-check it.PS. tar 1.22 compiled with gcc 4.5.0 works fine. ~amd64.Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHzCFLAGS=”-O2 -pipe -ggdb -march=native -msahf -mcx16 -fgcse-sm -fgcse-las -fgcse-after-reload -ftracer -floop-interchange -floop-strip-mine -floop-block”
@Branko We have a few alternative compilers in the tree already, but there are quite a few reasons not to go down that road: – the majority of the software out there is _only_ tested with GCC; – some of the packages will ignore what we tell them to use and (regrettably) will decide what to do by themselves; – we don’t have the manpower to manage multiple compilers.All in all, GCC will stand for a long time as our only supported compiler. On the other hand you _could_ try it yourself by using a trick “similar to the one I described”:https://blog.flameeyes.eu/2… to reset the CC/CXX variables… most packages should accept those, and those who don’t, well, will require a bug to be filed at least to that extent.@Maciej yes please, make sure they block “bug gcc-4.5”:http://bugs.gentoo.org/alia… (you can set that when filing the bug), so that we can see them right away.
The only problems I’ve had with GCC-4.5 is using the new -flto flag, an awful lot of packages fail with this.It’s probably the main reason they didn’t switch it on as default
Keep the bugs coming Diego!