R-4.3.3 +aqua-gcc12+builtin_lapack+cairo+gcc13+openmp+tcltk-x11 fails to build with the latest CLT on Sonoma 14.4 x86_64; builds on aarch64

[AP1010]

R-4.3.3 +aqua-gcc12+builtin_lapack+cairo+gcc13+openmp+tcltk-x11 and other variants (e.g. with accelerate or atlas) fails to build on Sonoma 14.4 x86_64. It builds on aarch64. It builds on x86_64 with the older CLT (15.1).

[AP1010]

Log file

[i0ntempest]

Remove /Library/Developer/CommandLineTools on your x86 machine, reinstall CLT, and try again.

[ryandesign (Ryan Carsten Schmidt)]

Why would that be the solution? What problem do you think has occurred with the user's installed command line tools?

[i0ntempest]

I didn't notice -gcc12 +gcc13 was specified. I don't know if upstream has moved to gcc13 yet but we set gcc12 in R portgroup. So maybe if that fails try +gcc12.

I suggested that because I've seen CLT reinstallation resolves random sdk related problems myself (like includes not found or unknown type). Can't cause any harm anyways.

[ryandesign (Ryan Carsten Schmidt)]

It sounds like you're suggesting there is some known process that causes the CLT to become corrupt. I'm not aware of such a phenomenon, and if it exists, it should be reported, documented, etc.

We do have documentation of a phenomenon where Apple updates used to delete the CLT receipt, as a result of which updates to the CLT were no longer suggested by Software Update and users ended up with unintentionally outdated CLT versions. As far as I know, that problem does not happen with current macOS anymore though, and according to this main.log file that didn't happen here (the receipt for CLT 15.3 was present, according to the log).

[i0ntempest]

Replying to ryandesign:

It sounds like you're suggesting there is some known process that causes the CLT to become corrupt.

That's possible. But it happens so rarely that I don't know how it got corrupted.

[AP1010]

Replying to i0ntempest:

Remove /Library/Developer/CommandLineTools on your x86 machine, reinstall CLT, and try again.

I tried reinstalling the CLT before (without prior removal, though). Will try again, once I am back at the Intel machine.

[AP1010]

Replying to i0ntempest:

I didn't notice -gcc12 +gcc13 was specified. I don't know if upstream has moved to gcc13 yet but we set gcc12 in R portgroup. So maybe if that fails try +gcc12.

I suggested that because I've seen CLT reinstallation resolves random sdk related problems myself (like includes not found or unknown type). Can't cause any harm anyways.

FWIW: gcc13 worked before. Up until the latest update.

[barracuda156]

Replying to i0ntempest:

I didn't notice -gcc12 +gcc13 was specified. I don't know if upstream has moved to gcc13 yet but we set gcc12 in R portgroup. So maybe if that fails try +gcc12.

We have gcc12 there for accidental reasons, essentially. The whole R (both port and PG) should be moved to use clang-17 (for x86 and aarch64) and gcc13 (for powerpc) with gfortran-13 (for everyone). It is not done so far because a) the idea was to move away from using compilers PG, and that needs rewriting some stuff and b) there was no urgency in that, since apparently everything works as is. (But depending on an extra gcc version is somewhat painful.)

I.e. this is not related to R upstream in any way.

[AP1010]

This has something to do with the CLT. I downgraded the CLT to15.1. R builds happily. Upgraded to the latest 15.3 - build fails.

[barracuda156]

Replying to AP1010:

This has something to do with the CLT. I downgraded the CLT to15.1. R builds happily. Upgraded to the latest 15.3 - build fails.

Could you please add the affected OS into keywords? Otherwise this gives impression that all Intel builds are broken, which is not the case.