Summary: | net-misc/wget-1.10.2 fails with confcache | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Jose daLuz <jdaluz> |
Component: | Core - Ebuild Support | Assignee: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | Dessa, ferringb, m.debruijne, maciek, maedhros, matrixhax0r, nightmorph, rhill |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 134459 | ||
Bug Blocks: |
Description
Jose daLuz
2006-03-11 19:15:58 UTC
same error here. syncing and remerging glibc made it go bye bye. my bad. this is a confcache bug. to reproduce: # rm /var/tmp/confcache/* && emerge =coreutils-5.94-r1 =wget-1.10.2 Works fine with the pre6-r5 for me. (In reply to comment #4) > Works fine with the pre6-r5 for me. What are you talking about? Did you comment on the wrong bug? adding RESTRICT="confcache" to the coreutils ebuild should be enough to fix this. (In reply to comment #6) > adding RESTRICT="confcache" to the coreutils ebuild should be enough to fix > this. Re-emerging coreutils with FEATURES="-confcache" didn't make any difference for me, but emerging wget without confcache _did_ work. i think that might have been because the config.cache value that causes the breakage was still in your confcache. using 'FEATURES="-confcache" emerge coreutils' won't clear the cache or update it, so wget will still fail. you're right that 'FEATURES="-confcache" emerge wget' would work too because the cache wouldn't be used, but then the bum entry from coreutils is still in the cache and could cause problems for other packages down the road. (In reply to comment #8) > i think that might have been because the config.cache value that causes the > breakage was still in your confcache. using 'FEATURES="-confcache" emerge > coreutils' won't clear the cache or update it, so wget will still fail. Ah, ok. So what is this bad config.cache value, and why is coreutils creating it? General goofyness i guess. coreutils' configure is setting: ac_cv_func_clock_gettime=${ac_cv_func_clock_gettime=yes} wget's configure w/o using the cache comes up with: ac_cv_func_clock_gettime=${ac_cv_func_clock_gettime=no} ac_cv_lib_rt_clock_gettime=${ac_cv_lib_rt_clock_gettime=yes} so wget using the coreutils cache thinks it can use clock_gettime without using an external library. in reality it can't, and needs to pass -lrt to have access to that function. i have no clue why coreutils can use clock_gettime natively while wget has to get it from a library. either way, putting a confcache restriction on the coreutils ebuild will fix this. *** Bug 124536 has been marked as a duplicate of this bug. *** *** Bug 106087 has been marked as a duplicate of this bug. *** *** Bug 125431 has been marked as a duplicate of this bug. *** (In reply to comment #0) Confirmed this happens for me with versions of gcc from 3.4.5 to 3.4.6 (stable x86) as I originally reported in awhile ago in bug 124536. Confcache is the culprit; see the above bug for my error message. Happens in all versions of Portage 2.1, including the latest. flameeyes...how 'bout a little love for this bug? :D (In reply to comment #14) As per ferringb's suggestion on another bug, deleting /var/tmp/confcache*, enabling FEATURES="confcache" in make.conf, and adding RESTRICT="confcache" to the wget ebuild, and emerging wget twice allows wget to be successfully built. I also first emerged coreutils with confcache enabled just to see if that would poison the subsequent wget compile (emerge coreutils wget), but wget built successfully each time. So that's sort of a good sign, though something still needs to be fixed elsewhere before RESTRICT="confcache" can be taken out of the wget ebuild. like i said before, the reason that works is because it just causes wget to not use the poisoned cache. however the problem is still there, just papered over. the proper solution is to add the restrict to the ebuild that does the poisoning, ie. coreutils. i've spoken to Brian and he confirmed it. with confcache bugs you have to find and fix the ebuild that introduces the invalid cache entry, _not_ the ebuild that dies because of it. FWIW, this also kills net-misc/ntp for the same reason and probably more that i just haven't run into yet. *** This bug has been marked as a duplicate of 134454 *** |