R @4.3.3+aqua-gcc12+builtin_lapack+cairo+gcc13+openmp+tcltk-x11: error: unknown type name 'CFAttributedStringRef'

[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.

[i0ntempest]

Replying to 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.

Just to confirm, upstream stated that R and its packages should be built using the same compiler but did not specify WHAT compiler(s) we should use (or they are actively supporting) - correct?

[barracuda156]

Replying to i0ntempest:

Just to confirm, upstream stated that R and its packages should be built using the same compiler but did not specify WHAT compiler(s) we should use (or they are actively supporting) - correct?

Well, I have not seen any strict requirement, but obviously we need something which supports C++17 and modern Fortran, since that is what many R ports use.

16. S. Just in case you haven’t seen this discussion: ​https://github.com/macports/macports-ports/pull/21614#issuecomment-1835385176

Others do not want to revbump R packages when we update compiler choice.

[ryandesign (Ryan Carsten Schmidt)]

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.

It certainly wouldn't be the first problem attributable to 15.3.

The error in the log is:

/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/CoreText.framework/Headers/CTLine.h:138:5: error: unknown type name 'CFAttributedStringRef'; did you mean 'CFMutableStringRef'?
    CFAttributedStringRef attrString ) CT_AVAILABLE(macos(10.5), ios(3.2), watchos(2.0), tvos(9.0));
    ^

According to Apple documentation ​CFAttributedStringRef was introduced in Mac OS X 10.4 and is not deprecated so it should still be there if the correct header is being included. Since it's CoreText that's trying to use this type, you'd think CoreText would include that header. As far as I can tell, it does. <CoreText/CTLine.h> includes <CoreFoundation/CoreFoundation.h>, which includes <CoreFoundation/CFAttributedString.h>*, which is where the CFAttributedStringRef typedef is.

*This is not new in 15.3 but the inclusion of CFAttributedString.h is guarded:

#if (TARGET_OS_OSX || TARGET_OS_IPHONE || TARGET_OS_WIN32 || 0)
#include <CoreFoundation/CFAttributedString.h>
#endif

I wonder if TARGET_OS_OSX is not getting set. They should be defined by <TargetConditionals.h> which <CoreFoundation/CoreFoundation.h> does include.

<TargetConditionals.h> has changed significantly between the Xcode 15.1 (macOS 14.2) version and the Xcode 15.3 (macOS 14.4) version. I imagine the intention was just to clean up the code and not change the behavior but maybe a mistake was made. I'll attach both versions if you want to examine the diff.

I don't have a machine with Xcode 15.3 in front of me but you might try printing out whether TARGET_OS_OSX is defined and what value it is defined to in this R file to see if we're looking in the right area.

[AP1010]

Unless I messed something up or didn't understand your request, the TARGET_OS_OSX is set to 0.

devQuartz.c:42:9: warning: TARGET_OS_OSX=0 [-W#pragma-messages]
#pragma message ("TARGET_OS_OSX=" STRINGIFY(TARGET_OS_OSX))

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #69674.

[ryandesign (Ryan Carsten Schmidt)]

Replying to AP1010:

TARGET_OS_OSX is set to 0.

Ok, then it sounds like we are looking in the right place. Now somebody needs to figure out why <TargetConditionals.h> is setting TARGET_OS_OSX to 0 when it should be setting it to 1.

[AP1010]

Newly released R @4.4.0_1 builds with the latest CLT.