When I try to emerge libol (in order to emerge syslog-ng), the emerge fails at the configure stage with the following errors : checking whether -lc should be explicitly linked in... rm: cannot remove `conftest': Is a directory rm: cannot remove `conftest': Is a directory the same problem comes back sevral time during configure which ends with : checking size of short... rm: cannot remove `conftest': Is a directory configure: error: cannot compute sizeof (short), 77 See `config.log' for more details. Reproducible: Always Steps to Reproduce: 1. emerge dev-libs/libol 2. 3. Actual Results: econf failed error. Launching ./configure from /var/tmp/portage/libol-0.3.14/work/libol-0.3.14 works. I couldn't find the conftest directory configure complains about in the whole /var/tmp tree.
The problem doesn't manifest itself without usersandbox in FEATURES.
Does libol-1.3.15 show the same issue?
On my 3 Gentoo boxes I just changed back to userpriv + usersandbox and tried again. On two of them the emerge works ok (for 0.3.14 as well as 0.3.15), the third can't emerge both versions with the error message initially reported.
Sounds like a local config problem somehow since it works for 2 of 3 machines there. I can't reproduce the problem here.
Last week (and I mean the whole week as this system is rather slow compiling...) I did an emerge -e world without any feature (I usualy have "ccache distcc userpriv usersandbox") and believe I found the problem in the process. The emerge repeatedly failed each time the cron jobs were launched. The only cron tasks that can interfere are an emerge sync and the default /etc/cron.daily/tmpwatch. Tmpwatch seems the most likely culprit as one example that I activated was: # Delete everything in PORTAGE_TMPDIR that hasn't been modified in 2 weeks. # if [[ -d ${PORTAGE_TMPDIR:-/var/tmp/portage} ]]; then ${TMPWATCH} --mtime --all 336 ${PORTAGE_TMPDIR:-/var/tmp/portage} fi If I'm not mistaken it will delete *source files* in use by the current emerge (the mtime are those stored in the source archives). I think the correct command should use --atime. As the above can leave the system in an unknow state after an emerge (results depend on the exact timings) I think this bug can be marked INVALID (I did a lot of long emerge sessions where tmpwatch could have bring nasty problems). app-admin/tmpwatch examples should be modified though, I'll check if a bug is already filled.
