I can't answer why it works in this particular case, but the generic
answer is that using a -j greater than one risks the launching of a job
that requires some output of another job not yet completed, or even
run. I suspect if you hunt through the build log, you will find the
missing file now created before it is used. If you look at the
specific line that created the file, you probably won't find it in the
log of the build that failed. My assumption is that assuring correct
ordering of tasks during a build is non-trivial in some (many?) cases,
and instead of configuring make (or whatever build system is used) to
do so, the developers just assume -j1. I'm pretty sure there are (or
used to be) some ebuilds which explicitly override and -j greater than
one, in cases where it is known to frequently fail. Again, if you're
looking for the reason this is so - I can't help.
Jack
On 2020.05.07 19:20, Victor Ivanov wrote:
In case anyone encounters the same issue, the problem was solved by
single threaded build using MAKEOPTS="-j1". No other config changes.
Why this works but not otherwise remains a mystery. I also had the
same
problem earlier today with dev-python/matplotlib-2.2.2-r1 except the
linker was complaining about an incompatible version of libc. Again
solved by -j1 and no other config modifications.
I have sometimes experienced this with some packages but exceptionally
rarely which is why it's not on usually on my "to try" list. If anyone
has any insights as to why this might be happening (in general), I
would
be grateful and happy to expand my knowledge :)
Cheers,
Victor
On 07/05/2020 15:53, Victor Ivanov wrote:
> Ah, thanks for pointing this out! It appears I'm blind ...
>
> It's rather surprising though, as sci-libs/lapack was neither
upgraded
> nor rebuilt. Since sci-libs/scipy wasn't upgraded either it ought to
> link just fine as it had previously been built against the same
version
> of sci-libs/lapack. I'm quite baffled.
>
> Rebuilding sci-libs/lapack didn't help and neither did ~amd64
keywording
> it. The error remains the same, which would make sense as there's
not
> really a new version of sci-libs/lapack.
>
> Cheers,
> Victor
>
> On 07/05/2020 15:04, Peter Humphrey wrote:
>> On Thursday, 7 May 2020 14:31:41 BST Victor Ivanov wrote:
>>> Hi all,
>>>
>>> For some reason SciPy fails to compile after today's Python 3.6 ->
>>> Python 3.7 global update. It was the only package that failed out
of all.
>>>
>>> Normally build.log (attached) is helpful enough to get me to
resolve the
>>> issue. However, it fails with a surprisingly unhelpful message
during a
>>> call to gfortran. Or maybe I'm unable to spot the proper error
message.
>>
>> Isn't this the cause?
>>
>> x86_64-pc-linux-gnu-gcc:
/var/tmp/portage/sci-libs/scipy-1.1.0/temp/tmpeyMzsQ/
>> source.c
>>
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
>> /var/tmp/portage/sci-libs/scipy-1.1.0/temp/ccGtNhqg.o: in function
`main':
>> source.c:(.text.startup+0x8c): undefined reference to `cblas_ddot'
>> collect2: error: ld returned 1 exit status
>>
>
