Post

Replies

Boosts

Views

Activity

Reply to Problems compiling with CLToolkit 15.3
I encountered this error while compiling code with a gcc compiler that worked with sdk's prior to 14.4 (like 14.2): /Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include/sys/cdefs.h:554:30: error: missing ')' after "__has_attribute" 554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage) | ^ /Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include/sys/cdefs.h:554:31: error: ':' without preceding '?' 554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage) | ^ In the /Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include/sys/cdefs.h file at line 554 (flagged by the compiler), the __has_cpp_attribute macro is using some apparent clang-centric input in this block (line 554-563 #if __has_cpp_attribute(clang::unsafe_buffer_usage) #define __has_safe_buffers 1 #define __unsafe_buffer_usage [[clang::unsafe_buffer_usage]] #elif __has_attribute(unsafe_buffer_usage) #define __has_safe_buffers 1 #define __unsafe_buffer_usage __attribute__((__unsafe_buffer_usage__)) #else #define __has_safe_buffers 0 #define __unsafe_buffer_usage #endif I was able to workaround the compilation issue by adding in guards based on whether __clang__ was defined, wrapping lines 554-570 Workaround change: #if defined(__clang__) // hacked in guard #if __has_cpp_attribute(clang::unsafe_buffer_usage) #define __has_safe_buffers 1 #define __unsafe_buffer_usage [[clang::unsafe_buffer_usage]] #elif __has_attribute(unsafe_buffer_usage) #define __has_safe_buffers 1 #define __unsafe_buffer_usage __attribute__((__unsafe_buffer_usage__)) #else #define __has_safe_buffers 0 #define __unsafe_buffer_usage #endif #if __has_safe_buffers #define __unsafe_buffer_usage_begin _Pragma("clang unsafe_buffer_usage begin") #define __unsafe_buffer_usage_end _Pragma("clang unsafe_buffer_usage end") #else #define __unsafe_buffer_usage_begin #define __unsafe_buffer_usage_end #endif #endif // hacked in endif I assumed a simple reproducer would just involve including cdefs.h and attempting to compile with gcc or g++, but that compiled fine for me in isolation. Attempted reproducer that compiled fine: // compile as: g++ cdfefs-issue-sdx144.c -I /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys #include <cdefs.h> int main () { return 0; } In any case, is it possible that the __has_cpp_attribute stuff as-is should be guarded based on whether clang is being used?
Mar ’24