Opened 8 months ago
Closed 7 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)
Change History (24)
Changed 8 months ago by AP1010
comment:1 Changed 8 months ago by jmroot (Joshua Root)
Cc: | i0ntempest barracuda156 added |
---|---|
Owner: | set to kjellpk |
Status: | new → assigned |
comment:2 follow-up: 7 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 follow-ups: 8 9 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 follow-up: 6 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 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 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 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 follow-up: 14 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 follow-ups: 12 16 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.
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 aarch64 → 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 aarch64 |
---|
comment:12 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 aarch64 → 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 |
comment:14 follow-up: 15 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 wholeR
(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 usingcompilers
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 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.
- 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 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 aarch64 → R @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)
Attachment: | TargetConditionals-macos14.2.h added |
---|
Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)
Attachment: | TargetConditionals-macos14.4.h added |
---|
comment:17 follow-up: 19 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))
comment:18 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | dbl001 added |
---|
Has duplicate #69674.
comment:19 Changed 8 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:21 Changed 7 months ago by i0ntempest
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Log file