The time, I need to emerge sci-libs/atlas-3.9.82, increased by a factor of 23-33 compared to older versions: root@dog:/root(38)# genlop -t atlas | tail -n 18 Wed May 9 13:53:00 2012 >>> sci-libs/atlas-3.9.74 merge time: 12 minutes and 34 seconds. Sat Jun 2 22:18:22 2012 >>> sci-libs/atlas-3.9.74 merge time: 12 minutes and 28 seconds. Sat Jun 9 21:25:47 2012 >>> sci-libs/atlas-3.9.77 merge time: 12 minutes and 23 seconds. Wed Jun 20 09:18:02 2012 >>> sci-libs/atlas-3.9.79 merge time: 13 minutes and 36 seconds. Fri Jun 29 17:29:49 2012 >>> sci-libs/atlas-3.9.80 merge time: 13 minutes and 40 seconds. Wed Jul 4 15:10:10 2012 >>> sci-libs/atlas-3.9.82 merge time: 5 hours, 30 minutes and 53 seconds. root@leopard:/usr/local/portage/sci-misc/imagej(25)# genlop -t atlas | tail -n 18 Tue May 8 10:01:43 2012 >>> sci-libs/atlas-3.9.74 merge time: 6 minutes and 57 seconds. Fri Jun 8 20:06:56 2012 >>> sci-libs/atlas-3.9.77 merge time: 7 minutes. Wed Jun 13 13:01:20 2012 >>> sci-libs/atlas-3.9.77 merge time: 7 minutes and 1 second. Tue Jun 19 12:09:58 2012 >>> sci-libs/atlas-3.9.79 merge time: 7 minutes and 8 seconds. Wed Jun 27 13:39:59 2012 >>> sci-libs/atlas-3.9.80 merge time: 7 minutes and 5 seconds. Wed Jul 4 13:24:23 2012 >>> sci-libs/atlas-3.9.82 merge time: 4 hours, 3 minutes and 48 seconds. Is this to expect or is it a bug?
probably due to the change in gcc detection.
Same problem here. I gave up after 5 hrs of compiling. It also left behind more than 4000 files(!) in /temp. look for files named like so "fileXXXXXX" I have never seen such a thing before.
So because gcc is not recognized it goes through all that tuning again and do not use already available timings. Is it due to something we do in gcc or does upstream have to rebuild all their timings as well?
should be fixed in 3.10.0 just released and science overlay was updated. however, i'm not sure how it behaves when cross-compiling.