macos: undo `availability` macro enabled by Homebrew gcc by vszakats · Pull Request #14155 · curl/curl

vszakats · 2024-07-11T13:01:32Z

Homebrew gcc builds starting with 12.4.0, 13.3.0 and 14.1.0 enabled
the availability attribute.

This broke builds because the way the Apple SDK uses attributes (when
available) are incompatible with how gcc accepts them. Causing these
errors:

  error: attributes should be specified before the declarator in a function definition
  error: expected ',' or '}' before

Upstream commits implementing the availability macro:
gcc-12: iains/gcc-12-branch@fd5530b
gcc-13: iains/gcc-13-branch@cb7e4ec
gcc-14: iains/gcc-14-branch@ff62a10

The project above is a Darwin gcc compatibility pack, that is applied
to Homebrew gcc builds.

This patch works by redefining the availability macro to an invalid
value, making __has_attribute(availability) checks fail, stopping
Apple SDK from inserting the incompatible attributes.

It also replaces the previous, local workaround for lib/macos.c.

Example with gcc 12.4.0 with macOS SDK 14.0 (Xcode 15.0.1):

In file included from <path-to-sdk>/MacOSX14.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:54,
                 from <path-to-sdk>/MacOSX14.0.sdk/System/Library/Frameworks/SystemConfiguration.framework/Headers/SCDynamicStoreCopySpecific.h:30,
                 from /Users/runner/work/curl/curl/lib/macos.c:33,
                 from /Users/runner/work/curl/curl/build/lib/CMakeFiles/libcurl_shared.dir/Unity/unity_0_c.c:244:
<path-to-sdk>/MacOSX14.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:126:1: error: attributes should be specified before the declarator in a function definition
  126 | CF_INLINE CFOptionFlags CFUserNotificationCheckBoxChecked(CFIndex i) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (8 + i)));}
      | ^~~~~~~~~

Ref: https://github.com/curl/curl/actions/runs/9787982387/job/27025351601?pr=14096#step:7:18

The gcc vs. llvm/clang incompatibility possibly tracked here upstream:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
More info:
llvm/llvm-project#81767
gcc-mirror/gcc@8433baa
https://discourse.llvm.org/t/changing-attribute-ast-printing-location-for-gcc-compatibility/73215
https://reviews.llvm.org/D159362

Follow-up to db135f8 #14119
Ref: #14091 (comment)
Fixes #13700
Cherry-picked from #14097
Closes #14155

Homebrew gcc builds starting with 12.4.0, 13.3.0 and 14.1.0 enabled the `availability` attribute. This broke builds because the way the Apple SDK uses attributes (when available) are incompatible with how gcc accepts them. Causing these errors: error: attributes should be specified before the declarator in a function definition error: expected ',' or '}' before Upstream commits implementing the `availability` macro: gcc-12: iains/gcc-12-branch@fd5530b gcc-13: iains/gcc-13-branch@cb7e4ec gcc-14: iains/gcc-14-branch@ff62a10 The project above is a Darwin gcc compatibility pack, that is applied to Homebrew gcc builds. This patch works by redefining the `availability` macro to an invalid value, making `__has_attribute(availability)` checks fail and stopping Apple SDK from inserting the incompatible attributes. Example with gcc 12.4.0 with macOS SDK 14.0 (Xcode 15.0.1): ``` In file included from <path-to-sdk>/MacOSX14.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:54, from <path-to-sdk>/MacOSX14.0.sdk/System/Library/Frameworks/SystemConfiguration.framework/Headers/SCDynamicStoreCopySpecific.h:30, from /Users/runner/work/curl/curl/lib/macos.c:33, from /Users/runner/work/curl/curl/build/lib/CMakeFiles/libcurl_shared.dir/Unity/unity_0_c.c:244: <path-to-sdk>/MacOSX14.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:126:1: error: attributes should be specified before the declarator in a function definition 126 | CF_INLINE CFOptionFlags CFUserNotificationCheckBoxChecked(CFIndex i) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (8 + i)));} | ^~~~~~~~~ ``` Ref: https://github.com/curl/curl/actions/runs/9787982387/job/27025351601?pr=14096#step:7:18 The gcc vs. llvm/clang incompatibility possibly tracked here upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796 More info here: llvm/llvm-project#81767 gcc-mirror/gcc@8433baa https://discourse.llvm.org/t/changing-attribute-ast-printing-location-for-gcc-compatibility/73215 https://reviews.llvm.org/D159362 Follow-up to db135f8 curl#14119 Ref: curl#14091 (comment) Fixes curl#13700 Cherry-picked from curl#14097 Closes #xxxxx

This PR began as an attempt to drop GCC support, after repeated reports on fallouts when trying to use it on macOS. Then it transformed into a 3-week project turning up the issues causing the fallouts, ending up including llvm and all available Xcode / macOS SDK, macOS runner image, build tools and compiler vendors and versions. Accumulating 400 sub-commits. I developed and tested all fixes under this PR, then merged them as separate patches. This PR retained CI jobs updates, extensively reworking and extending them: [1] At first it seemed GCC and the Apple SDK is "naturally" growing more incompatible, as Apple added further non-standard features to their headers. This is partly true, but reality is more complicated. Besides some issues local to curl, there were bugs in Apple SDK headers, Homebrew GCC builds, feature missing in the old llvm version pre-installed on GitHub CI runner images, and subtle incompatibilities between GCC and llvm/clang when handling language extensions. Resulting compiler errors seldom pointed to a useful direction, and internet search was silent about these issues too. Thus, I had to peel them off layer by layer, using trial and error, and by recognizing patterns of failures accross 150-200 builds combinations. Exposing configure logs, and curl_config.h in the CI logs helped too. 1. GCC header compatibility layer ("hack" as GCC calls it) The toughest issue is GCC's built-in compatibility layer: https://github.com/gcc-mirror/gcc/tree/master/fixincludes This patch layer is further patched by a "Darwin compatibility" project applied on top by Homebrew GCC via: https://github.com/iains/gcc-12-branch https://github.com/iains/gcc-13-branch https://github.com/iains/gcc-14-branch The hack layer is designed in a way that breaks more builds than it fixes, esp. in context of GHA runners. The idea is to build GCC specifically for the SDK for the target macOS version. The problem with this approach is that the Xcode + SDK installed on the local/CI machine often does not match with the SDK used on while building GCC on Homebrew's build machines. In these cases the GCC compatibility layer turns into an "uncompatibility" layer and consistently breaks builds. curl cannot offer a fix for this, because the solution (I found) is to patch the toolchain on the local machine. I implemented this for our CI builds and curl-for-win. In other case the user must do this patching manually, or choose a compatible GCC + Xcode/SDK combination. An upstream fix doesn't seem trivial either, because the issue is ingrained in the compatibility layer's design. Offering an `-fapplesdk` (or recognizing `-target`) option and/or fixing them within the compiler would seem like a more robust option, and also how mainline llvm solves this. Here's a table summarizing the GCC + SDK combinations and curl build failures: [2] More info: #10356 (comment) db135f8 #14119 macos: add workaround for gcc, non-c-ares, IPv6, compile error Ref: curl/curl-for-win@e2db3c4 Ref: curl/curl-for-win@f5c58d7 2. Homebrew GCC's `availability` extension A recent minor Homebrew GCC upgrade caused major breakage. The "Darwin compatibility" patch applied to GCC implemented the `availability` compiler attribute in GCC. Apple SDK detected this and enabled using them, but as it turns out GCC accepts compiler attributes with slightly different rules than llvm/clang, and how the Apple SDK uses them, breaking builds. Affected Homebrew GCC versions are: 12.4.0, 13.3.0 and 14.1.0. Possibly tracked here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796 More info: llvm/llvm-project#81767 Commit implementing the `availability` macro: gcc-12: iains/gcc-12-branch@fd5530b gcc-13: iains/gcc-13-branch@cb7e4ec gcc-14: iains/gcc-14-branch@ff62a10 That applied to Homebrew GCC (12.4.0): Homebrew/homebrew-core@b904223#diff-89dd0b4176eca7fcc24b591943509bf8a8d6ea904d71e5dfcd6b78fed62fc574R44-R48 Ref: #13700 More info: #14091 (comment) e91fcba #14155 macos: undo `availability` macro enabled by Homebrew gcc 3. Proprietary Apple SDK macros Apple SDK expects certain macros predefined by the compiler. Missing them may causes odd issues. Mainline llvm is keeping up with Apple clang, but it needs a fresh version, while the one installed on GitHub runners is old (v15). I patched these in `lib/curl_setup.h`. baa3270 #14134 build: fix llvm 16 or older + Xcode 15 or newer, and gcc 4. Apple SDK header bug Without certain predefined macros, SDK headers can take a codepath where it mis-defines its own `TARGET_OS_OSX` macro, which make it break its own headers later. I patched it in `lib/curl_setup.h`. ff784af #14159 build: fix llvm 17 and older + macOS SDK 14.4 and newer 5. `TargetConditionals.h` requires `sys/types.h` Fixed in curl. It caused feature-detection failurs with autotools, and could break builds in certain configurations. e1f6192 #14130 configure: fix `SystemConfiguration` detection 6. Differences between autotools and CMake compiler options Fixed it by syncing compiler warning options. 59cadac #14128 build: sync warning options between autotools, cmake & compilers 7. Differences between autotools and CMake dependency detection Fixed it by improving detection of libidn2, with some more fixes pending for the next feature window. f43adc2 #14137 cmake: detect `libidn2` also via `pkg-config` Ref: #14136 cmake: detect `nghttp2` via `pkg-config`, enable by default 8. libidn2 detection bug with CMake Fixed the root cause and also the trigger in the CI config. 764fbab #14175 cmake: fix builds with detected libidn2 lib but undetected header 9. Suppressed compiler warnings inside Apple-specific curl code Fixed these warnings, which allowed to stop silencing them. b05dc7e #14122 sectransp: fix `HAVE_BUILTIN_AVAILABLE` checks to not emit warnings 5fa534b #14162 sectransp: fix clang compiler warnings, stop silencing them 10. CMake mis-detecting a CA bundle path on macOS d2ef625 #14182 cmake: sync CA bundle/path detection with autotools 11. Failure to build tests with LibreSSL or wolfSSL with CMake Fixed by dropping unnecessary includes, makign test builds dependent on dependency headers. 3765d75 #14172 cmake: fix building `unit1600` due to missing `ssl/openssl.h` 12. curl tests with CMake curl's CMake was missing bits for running the C preprocessor accurately. It made tests 1119 and 1167 fail. I implemented the missing bits. efc2c51 #14124 tests: include current directory when running test Perl commands c09db8b #14129 cmake: create `configurehelp.pm` like autotools does 67cc1e3 #14125 test1119: adapt for `.md` input 13. GCC missing `__builtin_available()` support curl source code assumes this is available to enable certain codepaths. It's also intermixed with monotonic timer support. 14. Monotonic timer support with GCC Detected by GCC, while it probably shouldn't be. llvm/clang detects it depending on target OS version. I've been playing with this, but so far without a conclusion or fix. 15. Runtime/test failures with GCC I couldn't find the reason for most of this. A bunch of RTSP tests fail with GCC. SecureTransport + HTTP/2 is failing a bunch of tests. With OpenSSL it fails two of those. SecureTransport builds also fail one DoH test. 16. Runtime/test failure in llvm/clang AppleIDN support received a fix with two more remaining. fd02508 #14179 #14176 IDN: fix ß with AppleIDN 17. Other issues found and fixed while working on this: 2c15aa5 GHA/macos: delete misplaced `CFLAGS`, drop redundant CMake option 80fb7c0 #14126 configure: limit `SystemConfiguration` test to non-c-ares, IPv6 builds cfd6f43 #14127 build: tidy up `__builtin_available` feature checks (Apple) bae5553 #14174 runtests: show name and keywords for failed tests in summary 09cdf7e #14178 cmake: delete unused `HAVE_LIBSSH2`, `HAVE_LIBSOCKET` macros d3595c7 #14186 configure: CA bundle/path detection fixes 58772b0 #14187 runtests: set `SOURCE_DATE_EPOCH` to fix failing around midnight 18f1cd7 #14183 tests: sync feature names with `curl -V` 4c22d97 #14181 build: use `#error` instead of invalid syntax Pending merge:

This PR began as an attempt to drop GCC support, after repeated reports on fallouts when trying to use it on macOS. Then it transformed into a 3-week project turning up the issues causing the fallouts, ending up including llvm and all available Xcode / macOS SDK, macOS runner image, build tools and compiler vendors and versions. Accumulating 400 sub-commits. I developed and tested all fixes under this PR, then merged them as separate patches. This PR retained CI jobs updates, extensively reworking and extending them: [1] At first it seemed GCC and the Apple SDK is "naturally" growing more incompatible, as Apple added further non-standard features to their headers. This is partly true, but reality is more complicated. Besides some issues local to curl, there were bugs in Apple SDK headers, Homebrew GCC builds, feature missing in the old llvm version pre-installed on GitHub CI runner images, and subtle incompatibilities between GCC and llvm/clang when handling language extensions. Resulting compiler errors seldom pointed to a useful direction, and internet search was silent about these issues too. Thus, I had to peel them off layer by layer, using trial and error, and by recognizing patterns of failures accross 150-200 builds combinations. Exposing configure logs, and curl_config.h in the CI logs helped too. 1. GCC header compatibility layer ("hack" as GCC calls it) The toughest issue is GCC's built-in compatibility layer: https://github.com/gcc-mirror/gcc/tree/master/fixincludes This patch layer is further patched by a "Darwin compatibility" project applied on top by Homebrew GCC via: https://github.com/iains/gcc-12-branch https://github.com/iains/gcc-13-branch https://github.com/iains/gcc-14-branch The hack layer is designed in a way that breaks more builds than it fixes, esp. in context of GHA runners. The idea is to build GCC specifically for the SDK for the target macOS version. The problem with this approach is that the Xcode + SDK installed on the local/CI machine often does not match with the SDK used on while building GCC on Homebrew's build machines. In these cases the GCC compatibility layer turns into an "uncompatibility" layer and consistently breaks builds. curl cannot offer a fix for this, because the solution (I found) is to patch the toolchain on the local machine. I implemented this for our CI builds and curl-for-win. In other case the user must do this patching manually, or choose a compatible GCC + Xcode/SDK combination. An upstream fix doesn't seem trivial either, because the issue is ingrained in the compatibility layer's design. Offering an `-fapplesdk` (or recognizing `-target`) option and/or fixing them within the compiler would seem like a more robust option, and also how mainline llvm solves this. Here's a table summarizing the GCC + SDK combinations and curl build failures: [2] More info: #10356 (comment) db135f8 #14119 macos: add workaround for gcc, non-c-ares, IPv6, compile error Ref: curl/curl-for-win@e2db3c4 Ref: curl/curl-for-win@f5c58d7 2. Homebrew GCC's `availability` extension A recent minor Homebrew GCC upgrade caused major breakage. The "Darwin compatibility" patch applied to GCC implemented the `availability` compiler attribute in GCC. Apple SDK detected this and enabled using them, but as it turns out GCC accepts compiler attributes with slightly different rules than llvm/clang, and how the Apple SDK uses them, breaking builds. Affected Homebrew GCC versions are: 12.4.0, 13.3.0 and 14.1.0. Possibly tracked here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796 More info: llvm/llvm-project#81767 Commit implementing the `availability` macro: gcc-12: iains/gcc-12-branch@fd5530b gcc-13: iains/gcc-13-branch@cb7e4ec gcc-14: iains/gcc-14-branch@ff62a10 That applied to Homebrew GCC (12.4.0): Homebrew/homebrew-core@b904223#diff-89dd0b4176eca7fcc24b591943509bf8a8d6ea904d71e5dfcd6b78fed62fc574R44-R48 Ref: #13700 More info: #14091 (comment) e91fcba #14155 macos: undo `availability` macro enabled by Homebrew gcc 3. Proprietary Apple SDK macros Apple SDK expects certain macros predefined by the compiler. Missing them may causes odd issues. Mainline llvm is keeping up with Apple clang, but it needs a fresh version, while the one installed on GitHub runners is old (v15). I patched these in `lib/curl_setup.h`. baa3270 #14134 build: fix llvm 16 or older + Xcode 15 or newer, and gcc 4. Apple SDK header bug Without certain predefined macros, SDK headers can take a codepath where it mis-defines its own `TARGET_OS_OSX` macro, which make it break its own headers later. I patched it in `lib/curl_setup.h`. ff784af #14159 build: fix llvm 17 and older + macOS SDK 14.4 and newer 5. `TargetConditionals.h` requires `sys/types.h` Fixed in curl. It caused feature-detection failurs with autotools, and could break builds in certain configurations. e1f6192 #14130 configure: fix `SystemConfiguration` detection 6. Differences between autotools and CMake compiler options Fixed it by syncing compiler warning options. 59cadac #14128 build: sync warning options between autotools, cmake & compilers 7. Differences between autotools and CMake dependency detection Fixed it by improving detection of libidn2, with some more fixes pending for the next feature window. f43adc2 #14137 cmake: detect `libidn2` also via `pkg-config` Ref: #14136 cmake: detect `nghttp2` via `pkg-config`, enable by default 8. libidn2 detection bug with CMake Fixed the root cause and also the trigger in the CI config. 764fbab #14175 cmake: fix builds with detected libidn2 lib but undetected header 9. Suppressed compiler warnings inside Apple-specific curl code Fixed these warnings, which allowed to stop silencing them. b05dc7e #14122 sectransp: fix `HAVE_BUILTIN_AVAILABLE` checks to not emit warnings 5fa534b #14162 sectransp: fix clang compiler warnings, stop silencing them 10. CMake mis-detecting a CA bundle path on macOS d2ef625 #14182 cmake: sync CA bundle/path detection with autotools 11. Failure to build tests with LibreSSL or wolfSSL with CMake Fixed by dropping unnecessary includes, makign test builds dependent on dependency headers. 3765d75 #14172 cmake: fix building `unit1600` due to missing `ssl/openssl.h` 12. curl tests with CMake curl's CMake was missing bits for running the C preprocessor accurately. It made tests 1119 and 1167 fail. I implemented the missing bits. efc2c51 #14124 tests: include current directory when running test Perl commands c09db8b #14129 cmake: create `configurehelp.pm` like autotools does 67cc1e3 #14125 test1119: adapt for `.md` input 13. GCC missing `__builtin_available()` support curl source code assumes this is available to enable certain codepaths. It's also intermixed with monotonic timer support. 14. Monotonic timer support with GCC Detected by GCC, while it probably shouldn't be. llvm/clang detects it depending on target OS version. I've been playing with this, but so far without a conclusion or fix. 15. Runtime/test failures with GCC I couldn't find the reason for most of this. A bunch of RTSP tests fail with GCC. SecureTransport + HTTP/2 is failing a bunch of tests. With OpenSSL it fails two of those. SecureTransport builds also fail one DoH test. 16. Runtime/test failure in llvm/clang AppleIDN support received a fix with two more remaining. fd02508 #14179 #14176 IDN: fix ß with AppleIDN 17. Other issues found and fixed while working on this: 2c15aa5 GHA/macos: delete misplaced `CFLAGS`, drop redundant CMake option 80fb7c0 #14126 configure: limit `SystemConfiguration` test to non-c-ares, IPv6 builds cfd6f43 #14127 build: tidy up `__builtin_available` feature checks (Apple) bae5553 #14174 runtests: show name and keywords for failed tests in summary 09cdf7e #14178 cmake: delete unused `HAVE_LIBSSH2`, `HAVE_LIBSOCKET` macros d3595c7 #14186 configure: CA bundle/path detection fixes 58772b0 #14187 runtests: set `SOURCE_DATE_EPOCH` to fix failing around midnight 18f1cd7 #14183 tests: sync feature names with `curl -V` 4c22d97 #14181 build: use `#error` instead of invalid syntax Pending merges: - #14185 runtests: fold test details for GitHub CI runs - #14197 cmake: grab-bag of tidy-ups - #14196 configure: limit `__builtin_available` test to Darwin Summary: In general GCC doesn't seem to be a good fit with curl and macOS for now. These "lucky" combinations (GitHub Actions runner) will build out of the box now: macos-14 + Xcode 15.0.1 + gcc-11, gcc-12, gcc-14. The rest builds with the ugly workaround in place, but all this still leaves some runtime issues. More info and links in the commit messages and source code. [1]: This PR: - add info about target OS version requirements per feature, with OS names and release years. - stop using `-Wno-deprecated-declarations` to suppress warnings. - use `LDFLAGS=-w` to suppress 'object file was built for newer macOS version than being linked' warnings. (there were tens of thousands of them in some jobs) - allow overriding Xcode version in all jobs. - improve job names. - abbreviate CMake as CM, autotools as AM for more compact job names. - shorten job names by using `!` instead of `no-` and `non-`. - bump parellel tests to 10 (from 5). - drop using `--enable-maintainer-mode` `./configure` option. - add gcc-12 no-ssl, autotools job with tests, ignore failing test results. (It's not yet clear why gcc-12 builds have different runtime results than clang/llvm ones.) - add comments with OS names and release years next to version numbers, e.g. 10.15 # Catalina (2019) - fix broken gcc-12 SecureTransport build. - show compiler, Xcode, SDK, gcc hack SDK versions, Homebrew preinstalled packages and C compiler predefined macros for each job. Useful for debugging all the strange problems these builds might have. - merge brew bundle and install steps. - move step names to the top. - dump configure log for both cmake and autotools also for successful builds. Useful for debugging. - dump curl_config.h in short (sorted #defines) and full form. - add support for the mainline llvm compiler. - set sysroot for gcc and llvm. - add timeout for cmake jobs. - add new job matrix: combinations It supports building all possible compiler, runner image, Xcode/SDK combinations, with cmake and autotools, target OS versions and with or without SecureTransport. It's quick. GHA limits the maximum number of matrix jobs at 256. I used this as a test-rig to fix the macOS build fallouts with gcc and llvm. I settled with 16 jobs, trying to maximize fallout coverage. - implement hack to make Homebrew gcc work with all available SDKs. - add handy mini-table about Xcode / SDK versions, OS names, years for each GHA images, with the defaults. - add tests for cmake jobs. - make cmake config hack to link GnuTLS less intrusive. - stop ignoring test 1452, seems fine now. - fix to enable libpsl in autotools builds. - enable libpsl in cmake builds. - add an llvm job with tests (both autotools and cmake). - delete similar macOS jobs from Circle CI. GHA is now arm64 too. [2]: Homebrew GCC vs GHA runner images vs curl builds: ``` macOS Xcode gcc gcc SDK hacks Xcode SDK SDK major Build Compile (*def) (Homebrew) (CommandLineTools) versions error -------- -------- ---------- ------------------ ---------- --------- ----- --------------------- macos-12 13.1 GCC 11.4.0 MacOSX12 MacOSX12.0 macos-12 13.2.1 GCC 11.4.0 MacOSX12 MacOSX12.1 macos-12 13.3.1 GCC 11.4.0 MacOSX12 MacOSX12.3 macos-12 13.4.1 GCC 11.4.0 MacOSX12 MacOSX12.3 macos-12 14.0.1 GCC 11.4.0 MacOSX12 MacOSX12.3 macos-12 14.1 GCC 11.4.0 MacOSX12 MacOSX13.0 MISMATCH FAIL /Applications/Xcode_14.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/os/object.h:275:1: error: expected ';' before 'extern' macos-12 *14.2 GCC 11.4.0 MacOSX12 MacOSX13.1 MISMATCH FAIL /Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/os/object.h:275:1: error: expected ';' before 'extern' macos-13 14.1 GCC 11.4.0 MacOSX13 MacOSX13.0 macos-13 14.2 GCC 11.4.0 MacOSX13 MacOSX13.1 macos-13 14.3.1 GCC 11.4.0 MacOSX13 MacOSX13.3 macos-13 *15.0.1 GCC 11.4.0 MacOSX13 MacOSX14.0 MISMATCH FAIL /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dispatch/queue.h:103:1: error: unknown type name 'dispatch_queue_t' macos-13 15.1 GCC 11.4.0 MacOSX13 MacOSX14.2 MISMATCH FAIL /Applications/Xcode_15.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dispatch/queue.h:103:1: error: unknown type name 'dispatch_queue_t' macos-13 15.2 GCC 11.4.0 MacOSX13 MacOSX14.2 MISMATCH FAIL /Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dispatch/queue.h:103:1: error: unknown type name 'dispatch_queue_t' macos-14 14.3.1 GCC 11.4.0 MacOSX14 MacOSX13.3 MISMATCH FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-14 *15.0.1 GCC 11.4.0 MacOSX14 MacOSX14.0 macos-14 15.1 GCC 11.4.0 MacOSX14 MacOSX14.2 macos-14 15.2 GCC 11.4.0 MacOSX14 MacOSX14.2 macos-14 15.3 GCC 11.4.0 MacOSX14 MacOSX14.4 macos-14 15.4 GCC 11.4.0 MacOSX14 MacOSX14.5 macos-14 16.0 GCC 11.4.0 MacOSX14 MacOSX15.0 MISMATCH FAIL /opt/homebrew/Cellar/gcc@11/11.4.0/lib/gcc/11/gcc/aarch64-apple-darwin23/11/include-fixed/stdio.h:83:8: error: unknown type name 'FILE' macos-12 13.1 GCC 12.4.0 MacOSX12 MacOSX12.0 macos-12 13.2.1 GCC 12.4.0 MacOSX12 MacOSX12.1 macos-12 13.3.1 GCC 12.4.0 MacOSX12 MacOSX12.3 macos-12 13.4.1 GCC 12.4.0 MacOSX12 MacOSX12.3 macos-12 14.0.1 GCC 12.4.0 MacOSX12 MacOSX12.3 macos-12 14.1 GCC 12.4.0 MacOSX12 MacOSX13.0 MISMATCH FAIL /Applications/Xcode_14.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/os/object.h:275:1: error: expected ';' before 'extern' macos-12 *14.2 GCC 12.4.0 MacOSX12 MacOSX13.1 MISMATCH FAIL /Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/os/object.h:275:1: error: expected ';' before 'extern' macos-13 14.1 GCC 12.4.0 MacOSX13 MacOSX13.0 macos-13 14.2 GCC 12.4.0 MacOSX13 MacOSX13.1 macos-13 14.3.1 GCC 12.4.0 MacOSX13 MacOSX13.3 macos-13 *15.0.1 GCC 12.4.0 MacOSX13 MacOSX14.0 MISMATCH FAIL /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dispatch/queue.h:103:1: error: unknown type name 'dispatch_queue_t' macos-13 15.1 GCC 12.4.0 MacOSX13 MacOSX14.2 MISMATCH FAIL /Applications/Xcode_15.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dispatch/queue.h:103:1: error: unknown type name 'dispatch_queue_t' macos-13 15.2 GCC 12.4.0 MacOSX13 MacOSX14.2 MISMATCH FAIL /Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dispatch/queue.h:103:1: error: unknown type name 'dispatch_queue_t' macos-14 14.3.1 GCC 12.4.0 MacOSX14 MacOSX13.3 MISMATCH macos-14 *15.0.1 GCC 12.4.0 MacOSX14 MacOSX14.0 macos-14 15.1 GCC 12.4.0 MacOSX14 MacOSX14.2 macos-14 15.2 GCC 12.4.0 MacOSX14 MacOSX14.2 macos-14 15.3 GCC 12.4.0 MacOSX14 MacOSX14.4 macos-14 15.4 GCC 12.4.0 MacOSX14 MacOSX14.5 macos-14 16.0 GCC 12.4.0 MacOSX14 MacOSX15.0 MISMATCH FAIL /opt/homebrew/Cellar/gcc@12/12.4.0/lib/gcc/12/gcc/aarch64-apple-darwin23/12/include-fixed/stdio.h:83:8: error: unknown type name 'FILE' macos-12 13.1 GCC 13.3.0 MacOSX12 MacOSX12.0 macos-12 13.2.1 GCC 13.3.0 MacOSX12 MacOSX12.1 macos-12 13.3.1 GCC 13.3.0 MacOSX12 MacOSX12.3 macos-12 13.4.1 GCC 13.3.0 MacOSX12 MacOSX12.3 macos-12 14.0.1 GCC 13.3.0 MacOSX12 MacOSX12.3 macos-12 14.1 GCC 13.3.0 MacOSX12 MacOSX13.0 MISMATCH FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-12 *14.2 GCC 13.3.0 MacOSX12 MacOSX13.1 MISMATCH FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-13 14.1 GCC 13.3.0 MacOSX13 MacOSX13.0 macos-13 14.2 GCC 13.3.0 MacOSX13 MacOSX13.1 macos-13 14.3.1 GCC 13.3.0 MacOSX13 MacOSX13.3 macos-13 *15.0.1 GCC 13.3.0 MacOSX13 MacOSX14.0 MISMATCH FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-13 15.1 GCC 13.3.0 MacOSX13 MacOSX14.2 MISMATCH FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-13 15.2 GCC 13.3.0 MacOSX13 MacOSX14.2 MISMATCH FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-14 14.3.1 GCC 13.3.0 MacOSX14 MacOSX13.3 MISMATCH FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-14 *15.0.1 GCC 13.3.0 MacOSX14 MacOSX14.0 FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-14 15.1 GCC 13.3.0 MacOSX14 MacOSX14.2 FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-14 15.2 GCC 13.3.0 MacOSX14 MacOSX14.2 FAIL /Users/runner/work/curl/curl/bld/lib/curl_config.h:792:19: error: two or more data types in declaration specifiers macos-14 15.3 GCC 13.3.0 MacOSX14 MacOSX14.4 macos-14 15.4 GCC 13.3.0 MacOSX14 MacOSX14.5 macos-14 16.0 GCC 13.3.0 MacOSX14 MacOSX15.0 MISMATCH FAIL /opt/homebrew/Cellar/gcc@13/13.3.0/lib/gcc/13/gcc/aarch64-apple-darwin23/13/include-fixed/stdio.h:83:8: error: unknown type name 'FILE' macos-12 13.1 GCC 14.1.0 MacOSX12 MacOSX12.0 macos-12 13.2.1 GCC 14.1.0 MacOSX12 MacOSX12.1 macos-12 13.3.1 GCC 14.1.0 MacOSX12 MacOSX12.3 macos-12 13.4.1 GCC 14.1.0 MacOSX12 MacOSX12.3 macos-12 14.0.1 GCC 14.1.0 MacOSX12 MacOSX12.3 macos-12 14.1 GCC 14.1.0 MacOSX12 MacOSX13.0 MISMATCH FAIL /Applications/Xcode_14.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/os/object.h:275:1: error: expected ';' before 'extern' macos-12 *14.2 GCC 14.1.0 MacOSX12 MacOSX13.1 MISMATCH FAIL /Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/os/object.h:275:1: error: expected ';' before 'extern' macos-13 14.1 GCC 14.1.0 MacOSX13 MacOSX13.0 macos-13 14.2 GCC 14.1.0 MacOSX13 MacOSX13.1 macos-13 14.3.1 GCC 14.1.0 MacOSX13 MacOSX13.3 macos-13 *15.0.1 GCC 14.1.0 MacOSX13 MacOSX14.0 MISMATCH FAIL /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dispatch/queue.h:70:1: error: type defaults to 'int' in declaration of 'DISPATCH_DECL_FACTORY_CLASS_SWIFT' [-Wimplicit-int] macos-13 15.1 GCC 14.1.0 MacOSX13 MacOSX14.2 MISMATCH FAIL /Applications/Xcode_15.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dispatch/queue.h:70:1: error: type defaults to 'int' in declaration of 'DISPATCH_DECL_FACTORY_CLASS_SWIFT' [-Wimplicit-int] macos-13 15.2 GCC 14.1.0 MacOSX13 MacOSX14.2 MISMATCH FAIL /Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dispatch/queue.h:70:1: error: type defaults to 'int' in declaration of 'DISPATCH_DECL_FACTORY_CLASS_SWIFT' [-Wimplicit-int] macos-14 14.3.1 GCC 14.1.0 MacOSX14 MacOSX13.3 MISMATCH macos-14 *15.0.1 GCC 14.1.0 MacOSX14 MacOSX14.0 macos-14 15.1 GCC 14.1.0 MacOSX14 MacOSX14.2 macos-14 15.2 GCC 14.1.0 MacOSX14 MacOSX14.2 macos-14 15.3 GCC 14.1.0 MacOSX14 MacOSX14.4 macos-14 15.4 GCC 14.1.0 MacOSX14 MacOSX14.5 macos-14 16.0 GCC 14.1.0 MacOSX14 MacOSX15.0 MISMATCH FAIL /opt/homebrew/Cellar/gcc/14.1.0_1/lib/gcc/current/gcc/aarch64-apple-darwin23/14/include-fixed/stdio.h:83:8: error: unknown type name 'FILE' ``` Source: https://github.com/curl/curl/actions/runs/9883956647/job/27299564218 This commit fixes earlier commit 1e75edd, reverted in 41a7e0dcc9681afd91e066411bcee4f369c23366, where I cut the commit message in half by accident. The patch itself is identical. Closes #14097

saschasc · 2024-09-10T05:26:06Z

@vszakats I have the same issue with grpc. So there is no way in fixing that behaviour in Homebrew gcc?

vszakats · 2024-09-10T09:42:40Z

@saschasc An obvious fix would be to reverse the breaking patches in https://github.com/iains/gcc-*-branch/ (aka "hack" layers) and Homebrew GCC applying the fixed versions.

Perhaps the best would be to report this to either Homebrew or the hack-layer maintainer(s) to learn about the motivations for these patches and find the best way to fix it.

saschasc · 2024-10-06T09:21:54Z

It seems that they have been removed in the newest gcc 14.2 version.

See here iains/gcc-14-branch@b50a053

vszakats · 2024-10-06T10:45:11Z

Are you sure it is reverting the problematic availability patch? The linked patch seems to delete parts of the hack-layer patch that is now being dealt with its local implementation of availability. If so it means the problem is not resolved, and instead the project is doubling down on this feature. (Though all this is quite confusing, so I might be mis-reading it.)

availability support is still present in the latest master:
https://github.com/iains/gcc-14-branch/blob/848f27a4af59f534ab4c611d18257f66e2459a1d/gcc/config/darwin-protos.h#L91

(that said, this might be fixed in either gcc or llvm core code, and no longer problematic, but I haven't checked. edit: on a super quick glance, it isn't fixed by either.)

saschasc · 2024-10-09T18:42:55Z

@vszakats You are right. It doesn't solve the issue when importing the CoreFoundation headers. Some (or all?) of the so called hack layers were removed in the Darwin gcc fork.

Here is my understanding of the problem also after discussions with the Darwin GCC maintainer. See also here: https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax for better understanding.

Attributes in Function Definitions
In GCC, attributes are expected to be placed before the function type, not in the middle of the definition. This placement is pretty strict, which can be frustrating but ensures consistency. Here's a quick example:

cpp

__attribute__((noreturn)) void myFunction();

In Clang, the same attribute can be placed either before or after the function type without causing issues. This flexibility is one way Clang differs from GCC, even though Clang aims to be compatible with GCC's GNU attributes. For example:

cpp

void myFunction() __attribute__((noreturn));

Since Apple makes use of this in the CoreFoundation headers which results in difficulties when using GCC as compiler.

Remarks: Here is the issue that I've openend. The issue seems the same like in (lib)curl.
iains/gcc-14-branch#12

vszakats · 2024-10-09T21:04:51Z

@saschasc Thanks for raising this upstream. If clang-like positioning for __attribute__ would land in GCC, it'd be helpful indeed. It'd allow us to drop this individual hack from curl and start using these attributes as designed, with compatible GCC builds.

I guess the next elephant in the room is the issue of the GCC hack-layer being bound to a specific SDK version when building GCC itself, and the hack-layer breaking build when this doesn't match the actual SDK available (or selected) upon use. But, that's a different topic.

saschasc · 2024-10-22T08:46:03Z

A new Homebrew GCC version 14.2 should be released soon (see here Homebrew/homebrew-core#194797). Perhaps you would like to look at/test this again? I don't know what consequences the current libcurl hack has by simply ignoring the attributes.

Regarding the next elephant in the room: As I understand it, Iains is the only maintainer for gcc on macOS. If he had the resources, he would like to solve this differently. But without consideration from Apple this will be a difficult undertaking and clang and gcc have differences. But communication is very good and Iains was very helpful.

vszakats · 2024-10-22T10:22:20Z

A new Homebrew GCC version 14.2 should be released soon (see here Homebrew/homebrew-core#194797). Perhaps you would like to look at/test this again? I don't know what consequences the current libcurl hack has by simply ignoring the attributes.

The curl hack just deactivates the "availability" attribute, making the SDK headers think that it's unsupported by the compiler. It makes things behave like they did before the hack-layer enabled this attribute in these recent updates.

The updated patch looks promising. Once it hits the CI runner, I can test it by disabling the curl hack for 14.2. (I cannot test locally as Monterey is out of support and can't compile packages from source due the resources it needs.)

If it works, we can then disable the hack for 14.3 and newer. (We cannot pick up Homebrew package revisions from C headers, and feature detection for this feels overkill, so for 14.2 we need to assume it's unfixed.)

Regarding the next elephant in the room: As I understand it, Iains is the only maintainer for gcc on macOS. If he had the resources, he would like to solve this differently. But without consideration from Apple this will be a difficult undertaking and clang and gcc have differences. But communication is very good and Iains was very helpful.

It's a potentially large-scale fix. Understandable.

After the 14.2 fix SDKs will match indeed, but will mismatch again, when the GHA runner decides to upgrade Xcode or set a new default SDK. It's a constantly changing situation, where it sometimes matches, but most of the time doesn't. It can happen outside GHA too: Xcode and default SDK is updated on different schedules than Homebrew gcc bottle is rebuilt and deployed/updated.

vszakats · 2024-11-07T12:46:35Z

The Homebrew update of gcc 14.2.0_1 did not yet hit the curl CI, but hit curl-for-win's.
It broke the curl build there, as it seems the fix converts the existing curl workaround
into something breaking. It means that the curl workaround fixes 12.4.0, 13.3.0, 14.1.0,
14.2.0 but breaks 14.2.0_1. Opened #15508 as an attempt to fix it.

The problem is that there is no way to distinguish between 14.2.0 and 14.2.0_1 in
source (that I know of), so there will remain one broken gcc version/build, even after
merging the fix above. This broken version will be 14.2.0 which seems to be the
least bad option.

Also it seems there are no (not yet?) similar Homebrew updates for 12.4.0, 13.3.0, so
the workaround needs to be kept for those major versions.

Homebrew gcc 14.2.0_1 fixed the issue, and the workaround is no longer needed. Not only not needed, but the workaround breaks the fixed version. There is no way to detect if gcc is 14.2.0 or 14.2.0_1, so this patch drops the local workaround for both 14.2.0 releases. It means the issue will happen with 14.2.0, in which case the solution is to update to 14.2.0_1. Sadly it doesn't seem possible to fix both 14.2.0 and 14.2.0_1. (Perhaps unless doing an elaborate env detection, but that seems overkill for this single transition.) This issue did not yet hit CI, because the macos image is still coming with 14.2.0, but will hit once it's bumped to 14.2.0_1. Follow-up to e91fcba curl#14155

Homebrew gcc 14.2.0_1 fixed the issue, and the workaround is no longer needed. Not only not needed, but the workaround is breaking builds with the fixed gcc. Auto-detect the upstream fix and stop applying the local workaround if detected. Assisted-by: Bo Anderson Ref: Homebrew/homebrew-core#194778 (comment) Follow-up to e91fcba #14155 Closes #15508

Homebrew gcc 14.2.0_1 fixed the issue, and the workaround is no longer needed. Not only not needed, but the workaround is breaking builds with the fixed gcc. Auto-detect the upstream fix and stop applying the local workaround if detected. Assisted-by: Bo Anderson Ref: Homebrew/homebrew-core#194778 (comment) Follow-up to e91fcba curl#14155 Closes curl#15508

vszakats added build appleOS specific to an Apple operating system labels Jul 11, 2024

vszakats mentioned this pull request Jul 11, 2024

GCC-14 build fails on MacOSX using vcpkg #13700

Closed

name tweak

bcc5f10

vszakats closed this in e91fcba Jul 11, 2024

vszakats deleted the macos-gcc-fixup branch July 11, 2024 22:37

vszakats mentioned this pull request Jul 11, 2024

GHA/macos: improve, fix gcc/llvm, add new test matrix #14097

Closed

vszakats mentioned this pull request Nov 7, 2024

macos: disable gcc availability workaround as needed #15508

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

macos: undo `availability` macro enabled by Homebrew gcc#14155

macos: undo `availability` macro enabled by Homebrew gcc#14155
vszakats wants to merge 2 commits intocurl:masterfrom
vszakats:macos-gcc-fixup

vszakats commented Jul 11, 2024 •

edited

Loading

Uh oh!

saschasc commented Sep 10, 2024

Uh oh!

vszakats commented Sep 10, 2024

Uh oh!

saschasc commented Oct 6, 2024

Uh oh!

vszakats commented Oct 6, 2024 •

edited

Loading

Uh oh!

saschasc commented Oct 9, 2024

Uh oh!

vszakats commented Oct 9, 2024

Uh oh!

saschasc commented Oct 22, 2024

Uh oh!

vszakats commented Oct 22, 2024 •

edited

Loading

Uh oh!

vszakats commented Nov 7, 2024

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

vszakats commented Jul 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

saschasc commented Sep 10, 2024

Uh oh!

vszakats commented Sep 10, 2024

Uh oh!

saschasc commented Oct 6, 2024

Uh oh!

vszakats commented Oct 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

saschasc commented Oct 9, 2024

Uh oh!

vszakats commented Oct 9, 2024

Uh oh!

saschasc commented Oct 22, 2024

Uh oh!

vszakats commented Oct 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vszakats commented Nov 7, 2024

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

vszakats commented Jul 11, 2024 •

edited

Loading

vszakats commented Oct 6, 2024 •

edited

Loading

vszakats commented Oct 22, 2024 •

edited

Loading