When FEATURES includes distcc, dev-python/numpy-1.9.1 cannot be installed. This happens when both the distcc host and the client are AMD64. The host itself has dev-python/numpy-1.9.1 installed. Reproducible: Always Steps to Reproduce: 1. Enable distcc (e.g. FEATURES="splitdebug distcc distcc-pump") 2. emerge =dev-python/numpy-1.9.1 Actual Results: Build failure: see attached log. Expected Results: Numpy should install Immediately after generating the attached build.log, I ran FEATURES="-distcc" emerge =dev-python/numpy-1.9.1 --ask n It installed successfully.
Created attachment 390288 [details] emerge --info Output of `emerge --info`
Created attachment 390290 [details] build.log The full build log
Please post your `emerge -vpq dev-python/numpy' output in a comment.
[ebuild U ] dev-python/numpy-1.9.1 [1.8.2] USE="-doc -lapack {-test}" PYTHON_TARGETS="python2_7 python3_3 -python3_4"
Here as well. Same error, host amd64, client x86 with prior versions. [ebuild U ] dev-python/numpy-1.9.0-r1 [1.8.0-r1] USE="-doc -lapack {-test}" PYTHON_TARGETS="python2_7 python3_4 -python3_3"
Can this be confirmed, at least, since there's a second user who experiences it? I'm pretty sure it's a distcc issue, as the original report stated. It seems to affect cmake as well, but I'm having a hard time constructing a minimal exhibiting case.
(In reply to S. Gilles from comment #6) > Can this be confirmed, at least, since there's a second user who experiences > it? We don't use/distinguish/care about the two statuses. All bugs are confirmed to us :). Anyway, try FEATURES='distcc -distcc-pump'. The pump mode seems to be poorly implemented (thank you, Google) and causes tricky failures in many packages. And it's pretty much hard to nail this down well enough to fix it.
(In reply to Michał Górny from comment #7) > We don't use/distinguish/care about the two statuses. All bugs are confirmed > to us :). I understand now. Thanks, good to hear. > Anyway, try FEATURES='distcc -distcc-pump'. The pump mode seems to be poorly > implemented (thank you, Google) and causes tricky failures in many packages. > And it's pretty much hard to nail this down well enough to fix it. FEATURES="distcc -distcc-pump" results in many "Warning: INCLUDE_SERVER_PORT not set - did you forget to run under 'pump'?" messages, which I remember as being a symptom that prompted me to include distcc-pump in FEATURES in the first place. There are also lots of "Warning: failed to distribute, running locally instead" messages, but distcc is definitely in use for other files After a few minutes of this, Numpy successfully installs. I'm not too thrilled about the method, but at the very least that confirms that this is a problem with pump, and that running distcc without pump is a fine way of doing things (and by extension that I can ignore those nagging warning messages), so my original issue is solved. If I want to pursue this further, I guess I should look directly at pump. Thanks!
Same problem here upgrading from 1.9.1 to 1.9.2: File "numpy/core/setup_common.py", line 321, in long_double_representation raise ValueError("Could not lock sequences (%s)" % saw) No distcc involved. Observation: numpy 1.9.1 has emerged flawlessly on my system before, without any special preparations. When I try to re-emerge it now, it fails with the same error as 1.9.2. So something in the build environment has changed which messes up the numpy build (perhaps the upgrade from 4.8.x to gcc 4.9.2 or the latest glibc version)?
Obviously not "RESOLVED FIXED".
(In reply to Klaus Kusche from comment #10) > Obviously not "RESOLVED FIXED". please attach a full build.log of numpy-1.9.2 without distcc.
LTO problem. Builds fine with no-lto.
