Okay, flameeyes, same story. requested files will be attached in the next few minutes. :)
Created attachment 88023 [details] config.cache
Created attachment 88024 [details] config.log
Created attachment 88025 [details] genlop.txt
ac_cv_header_sys_utime_h=${ac_cv_header_sys_utime_h=no} Is the problem with config-cache ... you most likely do not have the header now but configure is finding it anyways. You need to go threw and remove all the utime_h entries and you can compile it until your heart is content.
ac_cv_func_clock_gettime=${ac_cv_func_clock_gettime=no} ac_cv_func_gettimeofday=${ac_cv_func_gettimeofday=yes} ac_cv_func_mktime=${ac_cv_func_mktime=yes} ac_cv_func_strptime=${ac_cv_func_strptime=yes} ac_cv_func_timegm=${ac_cv_func_timegm=yes} ac_cv_header_sys_time_h=${ac_cv_header_sys_time_h=yes} ac_cv_header_sys_utime_h=${ac_cv_header_sys_utime_h=no} ac_cv_header_time=${ac_cv_header_time=yes} ac_cv_header_utime_h=${ac_cv_header_utime_h=yes} ac_cv_lib_rt_clock_gettime=${ac_cv_lib_rt_clock_gettime=yes Just so the record is clear this is what wget picks up from my confcache which I have rebuilt 5 times now.
Should be fixed, if the problem re-presents itself, reopen.
*** Bug 135545 has been marked as a duplicate of this bug. ***
And how was it fixed? I was sent here because of duplicate bug #135545.
(In reply to comment #8) > And how was it fixed? I was sent here because of duplicate bug #135545. > See Bug 134459. Delete your confcache.
This is not fixed. Still getting failure even with confcache removed and emerge -e system rerun.
(In reply to comment #10) > This is not fixed. Still getting failure even with confcache removed and emerge > -e system rerun. After unmerging confcache and removing it from FEATURES, did you remember to rm /var/tmp/confcache/* ?
I hit this bug while doing a emerge -e world. I reran gcc-config and all was well. Therefor I suspect it's a gcc-config(eselect compiler) bug.
(In reply to comment #12) > I hit this bug while doing a emerge -e world. I reran gcc-config and all was > well. Therefor I suspect it's a gcc-config(eselect compiler) bug. > I dunno. It seems pretty well established in other bug reports that the cache is being poisoned by one particular package, which is what kills subsequent package compilations. AFAICT the big culprit is coreutils, which has some sort of missing/broken configure script that screws everything else over. I'm not aware of any other package being the cause of the poisoned cache at this time. Oh well, flameeyes masked confcache a few days ago anyway.
I'm closing them as UPSTREAM as for now I can't do much until Brian provides me a new version of confcache that allows to trace who poisoned the cache. This is also the main reason why confcache is masked right now.
*** Bug 143262 has been marked as a duplicate of this bug. ***
*** Bug 150441 has been marked as a duplicate of this bug. ***
*** Bug 226423 has been marked as a duplicate of this bug. ***
