Opened 8 months ago

Closed 6 months ago

#69526 closed defect (fixed)

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

Reported by: AP1010 Owned by: kjellpk (Kjell Konis)
Priority: Normal Milestone:
Component: ports Version: 2.9.1
Keywords: sonoma x86_64 Cc: i0ntempest, barracuda156, dbl001 (dbl)
Port: R

Description (last modified by 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).

Attachments (3)

main.log (412.3 KB) - added by AP1010 8 months ago.
Log file
TargetConditionals-macos14.2.h (25.4 KB) - added by ryandesign (Ryan Carsten Schmidt) 8 months ago.
TargetConditionals-macos14.4.h (17.6 KB) - added by ryandesign (Ryan Carsten Schmidt) 8 months ago.

Download all attachments as: .zip

Change History (24)

Changed 8 months ago by AP1010

Attachment: main.log added

Log file

comment:1 Changed 8 months ago by jmroot (Joshua Root)

Cc: i0ntempest barracuda156 added
Owner: set to kjellpk
Status: newassigned

comment:2 Changed 8 months ago by i0ntempest

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

comment:3 Changed 8 months ago by 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?

comment:4 Changed 8 months ago by 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.

comment:5 Changed 8 months ago by 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).

comment:6 in reply to:  5 Changed 8 months ago by 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.

comment:7 in reply to:  2 Changed 8 months ago by 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.

comment:8 in reply to:  4 Changed 8 months ago by 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.

comment:9 in reply to:  4 ; Changed 8 months ago by 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.

comment:10 Changed 8 months ago by 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.

Last edited 8 months ago by AP1010 (previous) (diff)

comment:11 Changed 8 months ago by AP1010

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

comment:12 in reply to:  10 Changed 8 months ago by 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.

comment:13 Changed 8 months ago by AP1010

Description: modified (diff)
Keywords: Sonoma 14.4 CLT 15.3 added
Summary: R-4.3.3 +aqua-gcc12+builtin_lapack+cairo+gcc13+openmp+tcltk-x11 fails to build with the latest CLT on x86_64; builds on aarch64R-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

comment:14 in reply to:  9 ; Changed 8 months ago by 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?

comment:15 in reply to:  14 Changed 8 months ago by 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.

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

comment:16 in reply to:  10 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)

Keywords: sonoma x86_64 added; Sonoma 14.4 CLT 15.3 removed
Summary: 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 aarch64R @4.3.3+aqua-gcc12+builtin_lapack+cairo+gcc13+openmp+tcltk-x11: error: unknown type name 'CFAttributedStringRef'

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.

Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)

Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)

comment:17 Changed 8 months ago by 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))

Last edited 8 months ago by AP1010 (previous) (diff)

comment:18 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: dbl001 added

Has duplicate #69674.

comment:19 in reply to:  17 Changed 7 months ago by 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.

comment:20 Changed 6 months ago by AP1010

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

Last edited 6 months ago by AP1010 (previous) (diff)

comment:21 Changed 6 months ago by i0ntempest

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.