Latest update broke OpenBLAS on 10.6 (x86_64 and ppc): Makefile.conf:8: *** missing separator. Stop.

[barracuda156]

See: https://trac.macports.org/ticket/66907
Log from 10.6.8 x86_64 with clang: https://build.macports.org/builders/ports-10.6_x86_64-builder/builds/149261/steps/install-port/logs/stdio

[martin-frbg]

You'll want to skip 0.3.22 for unrelated reasons, and I am not immediately aware of any relevant recent changes in the tools that generate Makefile.conf. From the log you posted, there appears to be a permission(?) problem with actions performed by c_check in relation to the identification of the C compiler - probably this is where the spurious dash comes from. the mktemp command on your system appears to require an additional argument, but I think this is not the root of the problem. The spurious dash seems to be spillover from the preceding CEXTRALIB line, but I do not see how this could happen unless the shell printf has an implicit line break at that line length. Does it work when you add USE_PERL=1 to employ the original perl-based tool ?

[barracuda156]

You'll want to skip 0.3.22 for unrelated reasons

@martin-frbg Could you refer to those please? Perhaps Macports maintainer @cjones051073 would want to be aware of that.

I am not immediately aware of any relevant changes in the tools that generate Makefile.conf

It was failing for some time with builds from master branch (see Trac ticket). However 0.3.21 built fine.

[martin-frbg]

Mhh, I also notice that you are applying a number of patches, including to c_check ?

[barracuda156]

Mhh, I also notice that you are applying a number of patches, including to c_check ?

Thank you for pointing that out. Those aren’t mine, I guess (I am not a maintainer of OpenBLAS), but I will look what they do.

Does it work when you add USE_PERL=1 to employ the original perl-based tool?

I will check that too.

[martin-frbg]

#3976 - a seemingly harmless change in GETRF/GETF2 that had unexpected consequences. 0.3.23 was released yesterday.

[martin-frbg]

Hm, could it be that your (cross)-compiler path length used to be shorter in the recent past ? That dash on line 8 definitely belongs on the end of line 7, there is no other output field between CROSS_SUFFIX and CROSS

[barracuda156]

Hm, could it be that your (cross)-compiler path length used to be shorter in the recent past ? That dash on line 8 definitely belongs on the end of line 7, there is no other output field between CROSS_SUFFIX and CROSS

This is very much unlikely (same prefix, same port name, why would it be different). In fact, as I recall, compiler is literally the same, there were no recent updates. Also, that does not explain why builds are fine on other systems.

[martin-frbg]

I have no idea what your other systems do, I do notice that the whole _opt_var_macports path is unusually long and there is no reason (in the script) why it would be split across lines 7&8 to create a spurious dash on line 8.

[barracuda156]

I have no idea what your other systems do, I do notice that the whole _opt_var_macports path is unusually long and there is no reason (in the script) why it would be split across lines 7&8 to create a spurious dash on line 8.

Well, in any case I cannot do anything about Macports paths – we need to fix OpenBLAS build for everyone, so local trickery with paths won’t solve the problem. But I am pretty sure nothing changed in this regard as compared to OpenBLAS 0.3.21.
I can actually revert locally to 0.3.21 and run configure to confirm it works with everything else identical. Gimme some time, machine is busy atm.

UPD. This commit broken it: aaaecdb
Reverting it fixes the build.

[martin-frbg]

Ah, thanks for the bisect - that is unfortunate, and I reckon it was at least the second attempt to support spaces here portably. Guess that line would have to be conditional on not being on macos, if nothing else

[martin-frbg]

So far I do not see why this would break, and I cannot reproduce the problem on either OSX-M1 or Linux-x86_64 even when faking your long compiler paths (unfortunately no easy osx-x86 access until next weekend, but the c_check is supposed to be universally applicable). I also do not get why a simple mktemp -d would fail with a usage message (either with or without replacing the original with gmktemp as one of your patches does - the d option and the behaviour in the absence of a template should be the same in either implementations)

(As an aside, your i386-Apple.diff seems to suggest that cpuid is available and reliable on 32bit ? Is that a specialty of the environment macports is expected to be used in, or could this patch be upstreamed here ?)

[kencu]

macports restricts the compiler selection for building openblas to newer clang and gcc versions.

It appears both of those compiler families support cpuid for i386.

So it’s upstreamable only if the appropriate compilers are used…