MacOS {12-14} GCC build failures #9997

EmilDohne · 2024-06-05T07:14:26Z

Description

When compiling my C++ Library on MacOS 12, 13 and 14 I get a bunch of error messages from the stdlib which I am assuming has to do with the GCC bump to 13.3 in the last runner updates.

Would it be possible to drop the version again or provide a XCode 15.3 build on the macos runners as it appears that the compilation works with that version (Tested by running the macos-latest runners with XCode 15.3 which resolves the issues).

/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:182:28: error: macro "__API_AVAILABLE2" requires 2 arguments, but only 1 given
  182 | __API_AVAILABLE(macos(10.0)) __IOS_PROHIBITED
      |                            ^
In file included from /Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/Availability.h:166,
                 from /Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/string.h:63,
                 from /Users/runner/work/PhotoshopAPI/PhotoshopAPI/thirdparty/libdeflate/lib/../common_defs.h:56,
                 from /Users/runner/work/PhotoshopAPI/PhotoshopAPI/thirdparty/libdeflate/lib/lib_common.h:40,
                 from /Users/runner/work/PhotoshopAPI/PhotoshopAPI/thirdparty/libdeflate/lib/utils.c:28:
/usr/local/Cellar/gcc@13/13.3.0/lib/gcc/13/gcc/x86_64-apple-darwin21/13/include-fixed/AvailabilityInternal.h:4502: note: macro "__API_AVAILABLE2" defined here
 4502 |     #define __API_AVAILABLE2(x,y) __API_A(x) __API_A(y)
      | 
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:184:1: error: expected ';' before 'int'
  184 | int      system(const char *) __DARWIN_ALIAS_C(system);
      | ^~~
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:220:[12](https://github.com/EmilDohne/PhotoshopAPI/actions/runs/9256194501/job/25825001717#step:5:13)3: error: macro "__API_AVAILABLE5" requires 5 arguments, but only 4 given
  220 | int ptsname_r(int fildes, char *buffer, size_t buflen) __API_AVAILABLE(macos(10.[13](https://github.com/EmilDohne/PhotoshopAPI/actions/runs/9256194501/job/25825001717#step:5:14).4), ios(11.3), tvos(11.3), watchos(4.3));
      |                                                                                                                           ^
/usr/local/Cellar/gcc@13/13.3.0/lib/gcc/13/gcc/x86_64-apple-darwin21/13/include-fixed/AvailabilityInternal.h:4505: note: macro "__API_AVAILABLE5" defined here
 4505 |     #define __API_AVAILABLE5(x,y,z,t,b) __API_A(x) __API_A(y) __API_A(z) __API_A(t) __API_A(b)
      | 
/Applications/Xcode_[14](https://github.com/EmilDohne/PhotoshopAPI/actions/runs/9256194501/job/25825001717#step:5:15).2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h: In function 'ptsname_r':
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:220:56: error: expected declaration specifiers before '__API_AVAILABLE5'
  220 | int ptsname_r(int fildes, char *buffer, size_t buflen) __API_AVAILABLE(macos(10.13.4), ios(11.3), tvos(11.3), watchos(4.3));
      |                                                        ^~~~~~~~~~~~~~~
In file included from /Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:256:
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_dev_t.h:31:31: error: storage class specified for parameter 'dev_t'
   31 | typedef __darwin_dev_t        dev_t;    /* device number */
      |                               ^~~~~
In file included from /Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:257:
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_mode_t.h:31:33: error: storage class specified for parameter 'mode_t'
   31 | typedef __darwin_mode_t         mode_t;
      |                                 ^~~~~~
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:299:34: error: expected ')' before 'char'
  299 | char    *devname_r(dev_t, mode_t, char *buf, int len);
      |                                  ^~~~~
      |                                  )
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:349:74: error: macro "__API_AVAILABLE5" requires 5 arguments, but only 4 given
  349 |         __API_AVAILABLE(macos(10.[15](https://github.com/EmilDohne/PhotoshopAPI/actions/runs/9256194501/job/25825001717#step:5:16)), ios(13.0), tvos(13.0), watchos(6.0));
      |                                                                          ^
/usr/local/Cellar/gcc@13/13.3.0/lib/gcc/13/gcc/x86_64-apple-darwin21/13/include-fixed/AvailabilityInternal.h:4505: note: macro "__API_AVAILABLE5" defined here
 4505 |     #define __API_AVAILABLE5(x,y,z,t,b) __API_A(x) __API_A(y) __API_A(z) __API_A(t) __API_A(b)
      | 
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:349:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__API_AVAILABLE5'
  349 |         __API_AVAILABLE(macos(10.15), ios(13.0), tvos(13.0), watchos(6.0));
      |         ^~~~~~~~~~~~~~~
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:357:73: error: macro "__API_AVAILABLE5" requires 5 arguments, but only 4 given
  357 |         __API_AVAILABLE(macos(11.0), ios(14.0), tvos(14.0), watchos(7.0));
      |                                                                         ^
/usr/local/Cellar/gcc@13/13.3.0/lib/gcc/13/gcc/x86_64-apple-darwin[21](https://github.com/EmilDohne/PhotoshopAPI/actions/runs/9256194501/job/25825001717#step:5:22)/13/include-fixed/AvailabilityInternal.h:4505: note: macro "__API_AVAILABLE5" defined here
 4505 |     #define __API_AVAILABLE5(x,y,z,t,b) __API_A(x) __API_A(y) __API_A(z) __API_A(t) __API_A(b)
      | 
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:357:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__API_AVAILABLE5'
  357 |         __API_AVAILABLE(macos(11.0), ios(14.0), tvos(14.0), watchos(7.0));
      |         ^~~~~~~~~~~~~~~
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:364:14: error: storage class specified for parameter 'suboptarg'
  364 | extern char *suboptarg;         /* getsubopt(3) external variable */
      |              ^~~~~~~~~

Here you can find the relevant builds, I have included one which I reran today which passed last week

Failure: https://github.com/EmilDohne/PhotoshopAPI/actions/runs/9256194501/job/25825001717
Success: https://github.com/EmilDohne/PhotoshopAPI/actions/runs/9256194501/job/25461660008

Platforms affected

Azure DevOps
GitHub Actions - Standard Runners
GitHub Actions - Larger Runners

Runner images affected

Image version and build link

Image: macos-13
Version: 20240526.1

https://github.com/EmilDohne/PhotoshopAPI/actions/runs/9365076914/job/25779508461

Is it regression?

Yes

Expected behavior

Compilation works as intended

Actual behavior

Compilation fails from stdlib

Repro steps

Compile PhotoshopAPI with GCC 13 on a MacOS runner
Failure

The text was updated successfully, but these errors were encountered:

quentin · 2024-06-05T15:26:52Z

Is this fixed by Homebrew/homebrew-core#173647 ?

EmilDohne · 2024-06-05T16:36:01Z

Looks like it is, since this isnt too critical right now I will wiat for this to be propagated to the runners instead of trying to shoehorn something together but thanks for the cross-link @quentin :)

Util the sdk support is propagated to the runners, see actions/runner-images#9997

erik-bershel · 2024-06-10T16:36:06Z

Hey @EmilDohne!

Should be fixed with the next image release as I see. Will be done by the end of this week.

EmilDohne · 2024-06-10T17:17:13Z

Hey @erik-bershel

Awesome! Thanks for looking into this :)

erik-bershel · 2024-06-14T08:13:21Z

Still working on the updates for macOS-12 runners. Moved to the next week. macOS-13 and macOS-14 based should be okay for now. May I ask you to check it, @EmilDohne? Thank you in advance.

EmilDohne · 2024-06-14T11:10:14Z

Hey @erik-bershel , unfortunately after running the ci again it still raises the same issues. I am currently away from home so I could investigate more once im back but for now it doesnt appear to work sadly :(

XCode 15.3 works however which is what i did before porting the patches but it isnt available on macos13 runners yet afaik

erik-bershel · 2024-06-14T11:22:41Z

XCode 15.3 works however which is what i did before porting the patches but it isnt available on macos13 runners yet afaik

Yeah, will never be tbh. It's macOS-14 privilege kinda. I expected that the update for GCC would help avoid the problem of incompatibility with previous versions of Xcode - unfortunately, my expectations were not met. 😞😞😞

Seems like GitHub Actions managed to break GCC 13 with a recent update: Worked: macOS 12.7.4 20240514.3 + GCC 13.2.0 Broken: macOS 12.7.5 20240602.1 + GCC 13.3.0 ^ ^^^^^ ^ Result "not found" for test "Looking for include file sys/xattr.h" is the earliest indicator something broke on their side during the build. Potentially related to actions/runner-images#9997 .

thejohnfreeman · 2024-06-18T01:06:22Z

This seems broken still on macos-14, 20240611.1.

actions/runner-images#9997 (comment)

erik-bershel · 2024-06-18T09:55:35Z

Hey @thejohnfreeman!

Be aware that the Xcode by default is 15.0.1 for macOS-14 (reference). Please, configure your job to work with the Xcode 15.3 or later in order to be compatible with GCC 13.3. Might be done using https://github.com/maxim-lobanov/setup-xcode

...by using GCC 12 on that platform. That's needed because the GCC13 builds started failing like this: /opt/homebrew/bin/gcc-13 -DLIBYANG_BUILD -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/plugins_exts -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/compat -I/opt/homebrew/include -DNDEBUG -O2 -Wall -Wextra -Wpedantic -std=c11 -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -fPIC -fvisibility=hidden -MD -MT CMakeFiles/yangobj.dir/src/dict.c.o -MF CMakeFiles/yangobj.dir/src/dict.c.o.d -o CMakeFiles/yangobj.dir/src/dict.c.o -c /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/pthread.h:57, from /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c:19: /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/time.h:198:67: error: macro "__API_AVAILABLE3" passed 4 arguments, but takes just 3 198 | __API_AVAILABLE(macosx(10.15), ios(13.0), tvos(13.0), watchos(6.0)) | ^ Bug: actions/runner-images#9997

...by using GCC 12 on that platform. That's needed because the GCC13 builds started failing like this: /opt/homebrew/bin/gcc-13 -DLIBYANG_BUILD -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/plugins_exts -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/compat -I/opt/homebrew/include -DNDEBUG -O2 -Wall -Wextra -Wpedantic -std=c11 -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -fPIC -fvisibility=hidden -MD -MT CMakeFiles/yangobj.dir/src/dict.c.o -MF CMakeFiles/yangobj.dir/src/dict.c.o.d -o CMakeFiles/yangobj.dir/src/dict.c.o -c /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/pthread.h:57, from /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c:19: /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/time.h:198:67: error: macro "__API_AVAILABLE3" passed 4 arguments, but takes just 3 198 | __API_AVAILABLE(macosx(10.15), ios(13.0), tvos(13.0), watchos(6.0)) | ^ Also unbreak some libyang `expect` tests, which have just started failing like this: 58/61 Test #61: yangre ............................***Failed 0.16 sec Tests running in interp: /usr/bin/tclsh Tests located in: /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/tests/yangre Tests running in: /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Temporary files stored in /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Test files run in separate interpreters Running tests that match: * Skipping test files that match: l.*.test Only running test files that match: *.test Tests began at Wed Jun 19 09:48:46 UTC 2024 arg.test ==== arg_empty Missing arguments FAILED ==== Contents of test case: ly_cmd_err "" "missing <string> parameter to process" ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ---- errorInfo: invalid command name "try" while executing "try { set results [exec -- $TUT {*}$cmd] set status 0 } trap CHILDSTATUS {results options} { # return code is not 0 ..." (procedure "ly_exec" line 3) invoked from within "ly_exec $cmd" (procedure "ly_cmd_err" line 3) invoked from within "ly_cmd_err "" "missing <string> parameter to process"" ("uplevel" body line 2) invoked from within "uplevel 1 $script" ---- errorCode: NONE ==== arg_empty FAILED I *think* that this smells like a difference in the provided version of `expect` which uses Tcl, and indeed, there's a small difference between these two image/sw versions: - https://github.com/actions/runner-images/blob/macos-12/20240602.1/images/macos/macos-12-Readme.md This one succeeds, and it says it has got a "Tcl/Tk 8.6.14" installed - https://github.com/actions/runner-images/blob/macos-13/20240616.1/images/macos/macos-13-Readme.md This one fails, and there's no mention of Tcl Try to fix this by always installing `expect` from Homebrew, and hope for the best. Yay, I love this blind debugging on a platform that I do not know at all. Fun, isn't it? Bug: actions/runner-images#9997

...by using GCC 12 on that platform. That's needed because the GCC13 builds started failing like this: /opt/homebrew/bin/gcc-13 -DLIBYANG_BUILD -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/plugins_exts -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/compat -I/opt/homebrew/include -DNDEBUG -O2 -Wall -Wextra -Wpedantic -std=c11 -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -fPIC -fvisibility=hidden -MD -MT CMakeFiles/yangobj.dir/src/dict.c.o -MF CMakeFiles/yangobj.dir/src/dict.c.o.d -o CMakeFiles/yangobj.dir/src/dict.c.o -c /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/pthread.h:57, from /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c:19: /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/time.h:198:67: error: macro "__API_AVAILABLE3" passed 4 arguments, but takes just 3 198 | __API_AVAILABLE(macosx(10.15), ios(13.0), tvos(13.0), watchos(6.0)) | ^ Also unbreak some libyang `expect` tests, which have just started failing like this: 58/61 Test #61: yangre ............................***Failed 0.16 sec Tests running in interp: /usr/bin/tclsh Tests located in: /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/tests/yangre Tests running in: /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Temporary files stored in /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Test files run in separate interpreters Running tests that match: * Skipping test files that match: l.*.test Only running test files that match: *.test Tests began at Wed Jun 19 09:48:46 UTC 2024 arg.test ==== arg_empty Missing arguments FAILED ==== Contents of test case: ly_cmd_err "" "missing <string> parameter to process" ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ---- errorInfo: invalid command name "try" while executing "try { set results [exec -- $TUT {*}$cmd] set status 0 } trap CHILDSTATUS {results options} { # return code is not 0 ..." (procedure "ly_exec" line 3) invoked from within "ly_exec $cmd" (procedure "ly_cmd_err" line 3) invoked from within "ly_cmd_err "" "missing <string> parameter to process"" ("uplevel" body line 2) invoked from within "uplevel 1 $script" ---- errorCode: NONE ==== arg_empty FAILED I *think* that this smells like a difference in the provided version of `expect` which uses Tcl, and indeed, there's a small difference between these two image/sw versions: - https://github.com/actions/runner-images/blob/macos-12/20240602.1/images/macos/macos-12-Readme.md This one succeeds, and it says it has got a "Tcl/Tk 8.6.14" installed - https://github.com/actions/runner-images/blob/macos-13/20240616.1/images/macos/macos-13-Readme.md This one fails, and there's no mention of Tcl Try to fix this by always installing `tcl-tk` from Homebrew, and hope for the best. Yay, I love this blind debugging on a platform that I do not know at all. Fun, isn't it? Bug: actions/runner-images#9997

First, let's try using GCC 12 on that platform. That's needed because the GCC13 builds started failing like this: /opt/homebrew/bin/gcc-13 -DLIBYANG_BUILD -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/plugins_exts -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/compat -I/opt/homebrew/include -DNDEBUG -O2 -Wall -Wextra -Wpedantic -std=c11 -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -fPIC -fvisibility=hidden -MD -MT CMakeFiles/yangobj.dir/src/dict.c.o -MF CMakeFiles/yangobj.dir/src/dict.c.o.d -o CMakeFiles/yangobj.dir/src/dict.c.o -c /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/pthread.h:57, from /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c:19: /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/time.h:198:67: error: macro "__API_AVAILABLE3" passed 4 arguments, but takes just 3 198 | __API_AVAILABLE(macosx(10.15), ios(13.0), tvos(13.0), watchos(6.0)) | ^ This gets fixed by using GCC 12, and with that, we can *build* the `libyang` project. What we cannot do is *test* it, because the following stuff started failing, apparently due to a change of `expect` version: 58/61 Test #61: yangre ............................***Failed 0.16 sec Tests running in interp: /usr/bin/tclsh Tests located in: /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/tests/yangre Tests running in: /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Temporary files stored in /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Test files run in separate interpreters Running tests that match: * Skipping test files that match: l.*.test Only running test files that match: *.test Tests began at Wed Jun 19 09:48:46 UTC 2024 arg.test ==== arg_empty Missing arguments FAILED ==== Contents of test case: ly_cmd_err "" "missing <string> parameter to process" ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ---- errorInfo: invalid command name "try" while executing "try { set results [exec -- $TUT {*}$cmd] set status 0 } trap CHILDSTATUS {results options} { # return code is not 0 ..." (procedure "ly_exec" line 3) invoked from within "ly_exec $cmd" (procedure "ly_cmd_err" line 3) invoked from within "ly_cmd_err "" "missing <string> parameter to process"" ("uplevel" body line 2) invoked from within "uplevel 1 $script" ---- errorCode: NONE ==== arg_empty FAILED Indeed, there's a small difference between these two image/sw versions: - https://github.com/actions/runner-images/blob/macos-12/20240602.1/images/macos/macos-12-Readme.md This one succeeds, and it says it has got a "Tcl/Tk 8.6.14" installed - https://github.com/actions/runner-images/blob/macos-13/20240616.1/images/macos/macos-13-Readme.md This one fails, and there's no mention of Tcl So, fix this by always installing `tcl-tk` from Homebrew. At this point we have `libyang` the C library built, installed and tested -- yay. It's time to move to the C++ code, which breaks with a wonderful internal error in the linker: FAILED: libyang-cpp.dylib : && /usr/local/bin/g++-12 -Wall -Wextra -pedantic -Woverloaded-virtual -Wimplicit-fallthrough -Wsuggest-override -O3 -DNDEBUG -arch x86_64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -dynamiclib -Wl,-headerpad_max_install_names -o libyang-cpp.dylib -install_name @rpath/libyang-cpp.dylib CMakeFiles/yang-cpp.dir/src/ChildInstantiables.cpp.o CMakeFiles/yang-cpp.dir/src/Context.cpp.o CMakeFiles/yang-cpp.dir/src/DataNode.cpp.o CMakeFiles/yang-cpp.dir/src/Enum.cpp.o CMakeFiles/yang-cpp.dir/src/Collection.cpp.o CMakeFiles/yang-cpp.dir/src/Module.cpp.o CMakeFiles/yang-cpp.dir/src/SchemaNode.cpp.o CMakeFiles/yang-cpp.dir/src/Set.cpp.o CMakeFiles/yang-cpp.dir/src/Type.cpp.o CMakeFiles/yang-cpp.dir/src/Utils.cpp.o CMakeFiles/yang-cpp.dir/src/utils/exception.cpp.o CMakeFiles/yang-cpp.dir/src/utils/ref_count.cpp.o CMakeFiles/yang-cpp.dir/src/utils/newPath.cpp.o -Wl,-rpath,/Users/runner/work/oopt-gnpy-libyang/target/lib /Users/runner/work/oopt-gnpy-libyang/target/lib/libyang.dylib && : -macosx_version_min has been renamed to -macos_version_min 0 0x10dd0cf43 __assert_rtn + 64 1 0x10dc0ef43 ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411 2 0x10dc2b431 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 19745 3 0x10dc3bb71 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 657 4 0x7ff806e9f066 _dispatch_client_callout2 + 8 5 0x7ff806eb218f _dispatch_apply_invoke_and_wait + 213 6 0x7ff806eb1692 _dispatch_apply_with_attr_f + 1207 7 0x7ff806eb1847 dispatch_apply + 45 8 0x10dcd4972 ld::AtomFileConsolidator::parseFiles(bool) + 370 9 0x10dc5bd67 main + 12263 ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336. collect2: error: ld returned 1 exit status Now, this looks a bug in the particular version of XCode that's used in this particular release of the Mac OS X GitHub CI runner, and the fix is apparently just to use a different version. Bug: actions/runner-images#9997 Bug: https://forums.developer.apple.com/forums/thread/737707 Bug: actions/runner-images#9273 Bug: Homebrew/homebrew-core#145991

First, let's try using GCC 12 on that platform. That's needed because the GCC13 builds started failing like this: /opt/homebrew/bin/gcc-13 -DLIBYANG_BUILD -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/plugins_exts -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/compat -I/opt/homebrew/include -DNDEBUG -O2 -Wall -Wextra -Wpedantic -std=c11 -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -fPIC -fvisibility=hidden -MD -MT CMakeFiles/yangobj.dir/src/dict.c.o -MF CMakeFiles/yangobj.dir/src/dict.c.o.d -o CMakeFiles/yangobj.dir/src/dict.c.o -c /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/pthread.h:57, from /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c:19: /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/time.h:198:67: error: macro "__API_AVAILABLE3" passed 4 arguments, but takes just 3 198 | __API_AVAILABLE(macosx(10.15), ios(13.0), tvos(13.0), watchos(6.0)) | ^ This gets fixed by using GCC 12, and with that, we can *build* the `libyang` project. What we cannot do is *test* it, because the following stuff started failing, apparently due to a change of `expect` version: 58/61 Test #61: yangre ............................***Failed 0.16 sec Tests running in interp: /usr/bin/tclsh Tests located in: /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/tests/yangre Tests running in: /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Temporary files stored in /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Test files run in separate interpreters Running tests that match: * Skipping test files that match: l.*.test Only running test files that match: *.test Tests began at Wed Jun 19 09:48:46 UTC 2024 arg.test ==== arg_empty Missing arguments FAILED ==== Contents of test case: ly_cmd_err "" "missing <string> parameter to process" ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ---- errorInfo: invalid command name "try" while executing "try { set results [exec -- $TUT {*}$cmd] set status 0 } trap CHILDSTATUS {results options} { # return code is not 0 ..." (procedure "ly_exec" line 3) invoked from within "ly_exec $cmd" (procedure "ly_cmd_err" line 3) invoked from within "ly_cmd_err "" "missing <string> parameter to process"" ("uplevel" body line 2) invoked from within "uplevel 1 $script" ---- errorCode: NONE ==== arg_empty FAILED Indeed, there's a small difference between these two image/sw versions: - https://github.com/actions/runner-images/blob/macos-12/20240602.1/images/macos/macos-12-Readme.md This one succeeds, and it says it has got a "Tcl/Tk 8.6.14" installed - https://github.com/actions/runner-images/blob/macos-13/20240616.1/images/macos/macos-13-Readme.md This one fails, and there's no mention of Tcl So, fix this by always installing `tcl-tk` from Homebrew. At this point we have `libyang` the C library built, installed and tested -- yay. It's time to move to the C++ code, which breaks with a wonderful internal error in the linker: FAILED: libyang-cpp.dylib : && /usr/local/bin/g++-12 -Wall -Wextra -pedantic -Woverloaded-virtual -Wimplicit-fallthrough -Wsuggest-override -O3 -DNDEBUG -arch x86_64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -dynamiclib -Wl,-headerpad_max_install_names -o libyang-cpp.dylib -install_name @rpath/libyang-cpp.dylib CMakeFiles/yang-cpp.dir/src/ChildInstantiables.cpp.o CMakeFiles/yang-cpp.dir/src/Context.cpp.o CMakeFiles/yang-cpp.dir/src/DataNode.cpp.o CMakeFiles/yang-cpp.dir/src/Enum.cpp.o CMakeFiles/yang-cpp.dir/src/Collection.cpp.o CMakeFiles/yang-cpp.dir/src/Module.cpp.o CMakeFiles/yang-cpp.dir/src/SchemaNode.cpp.o CMakeFiles/yang-cpp.dir/src/Set.cpp.o CMakeFiles/yang-cpp.dir/src/Type.cpp.o CMakeFiles/yang-cpp.dir/src/Utils.cpp.o CMakeFiles/yang-cpp.dir/src/utils/exception.cpp.o CMakeFiles/yang-cpp.dir/src/utils/ref_count.cpp.o CMakeFiles/yang-cpp.dir/src/utils/newPath.cpp.o -Wl,-rpath,/Users/runner/work/oopt-gnpy-libyang/target/lib /Users/runner/work/oopt-gnpy-libyang/target/lib/libyang.dylib && : -macosx_version_min has been renamed to -macos_version_min 0 0x10dd0cf43 __assert_rtn + 64 1 0x10dc0ef43 ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411 2 0x10dc2b431 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 19745 3 0x10dc3bb71 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 657 4 0x7ff806e9f066 _dispatch_client_callout2 + 8 5 0x7ff806eb218f _dispatch_apply_invoke_and_wait + 213 6 0x7ff806eb1692 _dispatch_apply_with_attr_f + 1207 7 0x7ff806eb1847 dispatch_apply + 45 8 0x10dcd4972 ld::AtomFileConsolidator::parseFiles(bool) + 370 9 0x10dc5bd67 main + 12263 ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336. collect2: error: ld returned 1 exit status Now, this looks a bug in the particular version of XCode that's used in this particular release of the Mac OS X GitHub CI runner, and the fix is apparently just to use a different version. That version however apparently cannot be the 15.1, because C++ exceptions are apparently FUBAR in there: 1/4 Test #1: test_context .....................Subprocess aborted***Exception: 0.02 sec libyang[0]: Unexpected end-of-input. (path: Line number 1.) terminate called after throwing an instance of 'libyang::ErrorWithCode' what(): Can't parse module: LY_EVALID [doctest] doctest version is "2.4.11" [doctest] run with "--help" for options =============================================================================== /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang-cpp/tests/context.cpp:66: TEST CASE: context parseModule invalid /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang-cpp/tests/context.cpp:66: FATAL ERROR: test case CRASHED: SIGABRT - Abort (abnormal termination) signal =============================================================================== /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang-cpp/tests/context.cpp:66: TEST CASE: context DEEPEST SUBCASE STACK REACHED (DIFFERENT FROM THE CURRENT ONE): parseModule invalid =============================================================================== [doctest] test cases: 1 | 0 passed | 1 failed | 1 skipped [doctest] assertions: 4 | 4 passed | 0 failed | [doctest] Status: FAILURE! 2/4 Test #4: test_unsafe ......................***Exception: SegFault 0.02 sec libunwind: _Unwind_GetDataRelBase - _Unwind_GetDataRelBase() not implemented Bug: actions/runner-images#9997 Bug: https://forums.developer.apple.com/forums/thread/737707 Bug: actions/runner-images#9273 Bug: Homebrew/homebrew-core#145991 Bug: https://stackoverflow.com/questions/78017671/runtime-issues-with-stdoptional-in-gcc-on-m2-mac

First, let's try using GCC 12 on that platform. That's needed because the GCC13 builds started failing like this: /opt/homebrew/bin/gcc-13 -DLIBYANG_BUILD -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/plugins_exts -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/compat -I/opt/homebrew/include -DNDEBUG -O2 -Wall -Wextra -Wpedantic -std=c11 -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -fPIC -fvisibility=hidden -MD -MT CMakeFiles/yangobj.dir/src/dict.c.o -MF CMakeFiles/yangobj.dir/src/dict.c.o.d -o CMakeFiles/yangobj.dir/src/dict.c.o -c /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/pthread.h:57, from /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c:19: /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/time.h:198:67: error: macro "__API_AVAILABLE3" passed 4 arguments, but takes just 3 198 | __API_AVAILABLE(macosx(10.15), ios(13.0), tvos(13.0), watchos(6.0)) | ^ This gets fixed by using GCC 12, and with that, we can *build* the `libyang` project. What we cannot do is *test* it, because the following stuff started failing, apparently due to a change of `expect` version: 58/61 Test #61: yangre ............................***Failed 0.16 sec Tests running in interp: /usr/bin/tclsh Tests located in: /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/tests/yangre Tests running in: /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Temporary files stored in /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Test files run in separate interpreters Running tests that match: * Skipping test files that match: l.*.test Only running test files that match: *.test Tests began at Wed Jun 19 09:48:46 UTC 2024 arg.test ==== arg_empty Missing arguments FAILED ==== Contents of test case: ly_cmd_err "" "missing <string> parameter to process" ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ---- errorInfo: invalid command name "try" while executing "try { set results [exec -- $TUT {*}$cmd] set status 0 } trap CHILDSTATUS {results options} { # return code is not 0 ..." (procedure "ly_exec" line 3) invoked from within "ly_exec $cmd" (procedure "ly_cmd_err" line 3) invoked from within "ly_cmd_err "" "missing <string> parameter to process"" ("uplevel" body line 2) invoked from within "uplevel 1 $script" ---- errorCode: NONE ==== arg_empty FAILED Indeed, there's a small difference between these two image/sw versions: - https://github.com/actions/runner-images/blob/macos-12/20240602.1/images/macos/macos-12-Readme.md This one succeeds, and it says it has got a "Tcl/Tk 8.6.14" installed - https://github.com/actions/runner-images/blob/macos-13/20240616.1/images/macos/macos-13-Readme.md This one fails, and there's no mention of Tcl So, fix this by always installing `tcl-tk` from Homebrew. At this point we have `libyang` the C library built, installed and tested -- yay. It's time to move to the C++ code, which breaks with a wonderful internal error in the linker: FAILED: libyang-cpp.dylib : && /usr/local/bin/g++-12 -Wall -Wextra -pedantic -Woverloaded-virtual -Wimplicit-fallthrough -Wsuggest-override -O3 -DNDEBUG -arch x86_64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -dynamiclib -Wl,-headerpad_max_install_names -o libyang-cpp.dylib -install_name @rpath/libyang-cpp.dylib CMakeFiles/yang-cpp.dir/src/ChildInstantiables.cpp.o CMakeFiles/yang-cpp.dir/src/Context.cpp.o CMakeFiles/yang-cpp.dir/src/DataNode.cpp.o CMakeFiles/yang-cpp.dir/src/Enum.cpp.o CMakeFiles/yang-cpp.dir/src/Collection.cpp.o CMakeFiles/yang-cpp.dir/src/Module.cpp.o CMakeFiles/yang-cpp.dir/src/SchemaNode.cpp.o CMakeFiles/yang-cpp.dir/src/Set.cpp.o CMakeFiles/yang-cpp.dir/src/Type.cpp.o CMakeFiles/yang-cpp.dir/src/Utils.cpp.o CMakeFiles/yang-cpp.dir/src/utils/exception.cpp.o CMakeFiles/yang-cpp.dir/src/utils/ref_count.cpp.o CMakeFiles/yang-cpp.dir/src/utils/newPath.cpp.o -Wl,-rpath,/Users/runner/work/oopt-gnpy-libyang/target/lib /Users/runner/work/oopt-gnpy-libyang/target/lib/libyang.dylib && : -macosx_version_min has been renamed to -macos_version_min 0 0x10dd0cf43 __assert_rtn + 64 1 0x10dc0ef43 ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411 2 0x10dc2b431 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 19745 3 0x10dc3bb71 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 657 4 0x7ff806e9f066 _dispatch_client_callout2 + 8 5 0x7ff806eb218f _dispatch_apply_invoke_and_wait + 213 6 0x7ff806eb1692 _dispatch_apply_with_attr_f + 1207 7 0x7ff806eb1847 dispatch_apply + 45 8 0x10dcd4972 ld::AtomFileConsolidator::parseFiles(bool) + 370 9 0x10dc5bd67 main + 12263 ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336. collect2: error: ld returned 1 exit status Now, this looks a bug in the particular version of XCode that's used in this particular release of the Mac OS X GitHub CI runner, and the fix is apparently just to use a different version. That version however apparently cannot be the 15.1, because C++ exceptions are apparently FUBAR in there: 1/4 Test #1: test_context .....................Subprocess aborted***Exception: 0.02 sec libyang[0]: Unexpected end-of-input. (path: Line number 1.) terminate called after throwing an instance of 'libyang::ErrorWithCode' what(): Can't parse module: LY_EVALID [doctest] doctest version is "2.4.11" [doctest] run with "--help" for options =============================================================================== /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang-cpp/tests/context.cpp:66: TEST CASE: context parseModule invalid /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang-cpp/tests/context.cpp:66: FATAL ERROR: test case CRASHED: SIGABRT - Abort (abnormal termination) signal =============================================================================== /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang-cpp/tests/context.cpp:66: TEST CASE: context DEEPEST SUBCASE STACK REACHED (DIFFERENT FROM THE CURRENT ONE): parseModule invalid =============================================================================== [doctest] test cases: 1 | 0 passed | 1 failed | 1 skipped [doctest] assertions: 4 | 4 passed | 0 failed | [doctest] Status: FAILURE! 2/4 Test #4: test_unsafe ......................***Exception: SegFault 0.02 sec libunwind: _Unwind_GetDataRelBase - _Unwind_GetDataRelBase() not implemented FIXME: At that point everything builds, but macOS 12 wheels fail to install. Bug: actions/runner-images#9997 Bug: https://forums.developer.apple.com/forums/thread/737707 Bug: actions/runner-images#9273 Bug: Homebrew/homebrew-core#145991 Bug: https://stackoverflow.com/questions/78017671/runtime-issues-with-stdoptional-in-gcc-on-m2-mac

First, let's try using GCC 12 on that platform. That's needed because the GCC13 builds started failing like this: /opt/homebrew/bin/gcc-13 -DLIBYANG_BUILD -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src -I/Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/plugins_exts -I/Users/runner/work/oopt-gnpy-libyang/build-libyang/compat -I/opt/homebrew/include -DNDEBUG -O2 -Wall -Wextra -Wpedantic -std=c11 -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -fPIC -fvisibility=hidden -MD -MT CMakeFiles/yangobj.dir/src/dict.c.o -MF CMakeFiles/yangobj.dir/src/dict.c.o.d -o CMakeFiles/yangobj.dir/src/dict.c.o -c /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c In file included from /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/include/pthread.h:57, from /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/src/dict.c:19: /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/time.h:198:67: error: macro "__API_AVAILABLE3" passed 4 arguments, but takes just 3 198 | __API_AVAILABLE(macosx(10.15), ios(13.0), tvos(13.0), watchos(6.0)) | ^ This gets fixed by using GCC 12, and with that, we can *build* the `libyang` project. What we cannot do is *test* it, because the following stuff started failing, apparently due to a change of `expect` version: 58/61 Test #61: yangre ............................***Failed 0.16 sec Tests running in interp: /usr/bin/tclsh Tests located in: /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang/tests/yangre Tests running in: /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Temporary files stored in /Users/runner/work/oopt-gnpy-libyang/build-libyang/tests/yangre Test files run in separate interpreters Running tests that match: * Skipping test files that match: l.*.test Only running test files that match: *.test Tests began at Wed Jun 19 09:48:46 UTC 2024 arg.test ==== arg_empty Missing arguments FAILED ==== Contents of test case: ly_cmd_err "" "missing <string> parameter to process" ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ---- errorInfo: invalid command name "try" while executing "try { set results [exec -- $TUT {*}$cmd] set status 0 } trap CHILDSTATUS {results options} { # return code is not 0 ..." (procedure "ly_exec" line 3) invoked from within "ly_exec $cmd" (procedure "ly_cmd_err" line 3) invoked from within "ly_cmd_err "" "missing <string> parameter to process"" ("uplevel" body line 2) invoked from within "uplevel 1 $script" ---- errorCode: NONE ==== arg_empty FAILED Indeed, there's a small difference between these two image/sw versions: - https://github.com/actions/runner-images/blob/macos-12/20240602.1/images/macos/macos-12-Readme.md This one succeeds, and it says it has got a "Tcl/Tk 8.6.14" installed - https://github.com/actions/runner-images/blob/macos-13/20240616.1/images/macos/macos-13-Readme.md This one fails, and there's no mention of Tcl So, fix this by always installing `tcl-tk` from Homebrew. As a bonus, we can now drop the manual workaround for libyang tests "without expect". Yay, one fewer FIXME. At this point we have `libyang` the C library built, installed and tested -- yay. It's time to move to the C++ code, which breaks with a wonderful internal error in the linker: FAILED: libyang-cpp.dylib : && /usr/local/bin/g++-12 -Wall -Wextra -pedantic -Woverloaded-virtual -Wimplicit-fallthrough -Wsuggest-override -O3 -DNDEBUG -arch x86_64 -isysroot /Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -mmacosx-version-min=13.0 -dynamiclib -Wl,-headerpad_max_install_names -o libyang-cpp.dylib -install_name @rpath/libyang-cpp.dylib CMakeFiles/yang-cpp.dir/src/ChildInstantiables.cpp.o CMakeFiles/yang-cpp.dir/src/Context.cpp.o CMakeFiles/yang-cpp.dir/src/DataNode.cpp.o CMakeFiles/yang-cpp.dir/src/Enum.cpp.o CMakeFiles/yang-cpp.dir/src/Collection.cpp.o CMakeFiles/yang-cpp.dir/src/Module.cpp.o CMakeFiles/yang-cpp.dir/src/SchemaNode.cpp.o CMakeFiles/yang-cpp.dir/src/Set.cpp.o CMakeFiles/yang-cpp.dir/src/Type.cpp.o CMakeFiles/yang-cpp.dir/src/Utils.cpp.o CMakeFiles/yang-cpp.dir/src/utils/exception.cpp.o CMakeFiles/yang-cpp.dir/src/utils/ref_count.cpp.o CMakeFiles/yang-cpp.dir/src/utils/newPath.cpp.o -Wl,-rpath,/Users/runner/work/oopt-gnpy-libyang/target/lib /Users/runner/work/oopt-gnpy-libyang/target/lib/libyang.dylib && : -macosx_version_min has been renamed to -macos_version_min 0 0x10dd0cf43 __assert_rtn + 64 1 0x10dc0ef43 ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411 2 0x10dc2b431 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 19745 3 0x10dc3bb71 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 657 4 0x7ff806e9f066 _dispatch_client_callout2 + 8 5 0x7ff806eb218f _dispatch_apply_invoke_and_wait + 213 6 0x7ff806eb1692 _dispatch_apply_with_attr_f + 1207 7 0x7ff806eb1847 dispatch_apply + 45 8 0x10dcd4972 ld::AtomFileConsolidator::parseFiles(bool) + 370 9 0x10dc5bd67 main + 12263 ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336. collect2: error: ld returned 1 exit status Now, this looks a bug in the particular version of XCode that's used in this particular release of the Mac OS X GitHub CI runner, and the fix is apparently just to use a different version. That version however apparently cannot be the 15.1, because C++ exceptions are apparently FUBAR in there: 1/4 Test #1: test_context .....................Subprocess aborted***Exception: 0.02 sec libyang[0]: Unexpected end-of-input. (path: Line number 1.) terminate called after throwing an instance of 'libyang::ErrorWithCode' what(): Can't parse module: LY_EVALID [doctest] doctest version is "2.4.11" [doctest] run with "--help" for options =============================================================================== /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang-cpp/tests/context.cpp:66: TEST CASE: context parseModule invalid /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang-cpp/tests/context.cpp:66: FATAL ERROR: test case CRASHED: SIGABRT - Abort (abnormal termination) signal =============================================================================== /Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/libyang-cpp/tests/context.cpp:66: TEST CASE: context DEEPEST SUBCASE STACK REACHED (DIFFERENT FROM THE CURRENT ONE): parseModule invalid =============================================================================== [doctest] test cases: 1 | 0 passed | 1 failed | 1 skipped [doctest] assertions: 4 | 4 passed | 0 failed | [doctest] Status: FAILURE! 2/4 Test #4: test_unsafe ......................***Exception: SegFault 0.02 sec libunwind: _Unwind_GetDataRelBase - _Unwind_GetDataRelBase() not implemented At that point everything builds, but macOS 12 wheels fail to install. That's because "something" has changed in the CI images, and the provided Python interpreter does not use the 12_04 tag, but it instead stops at version 12_0, like this: $ pip install -vvv --only-binary :all: --no-index --find-links=${GITHUB_WORKSPACE//\\//}/wheelhouse oopt-gnpy-libyang ... Skipping link: none of the wheel's tags (cp311-cp311-macosx_12_4_x86_64) are compatible (run pip debug --verbose to show compatible tags): file:///Users/runner/work/oopt-gnpy-libyang/oopt-gnpy-libyang/wheelhouse/oopt_gnpy_libyang-0.0.15.dev1%2Bga16eba9-cp311-cp311-macosx_12_4_x86_64.whl ... $ pip debug --verbose ... Compatible tags: 2264 cp311-cp311-macosx_12_0_x86_64 cp311-cp311-macosx_12_0_intel cp311-cp311-macosx_12_0_fat64 cp311-cp311-macosx_12_0_fat32 cp311-cp311-macosx_12_0_universal2 cp311-cp311-macosx_12_0_universal ... Since there's been no reason given on why we might need version 12.4 instead of just 12.0 in the original commit which added support for Mac OS buidls in the first place, let's just call this 12.0 and hope that the ABI overlords which control the C++ STL are on our side. Bug: actions/runner-images#9997 Bug: https://forums.developer.apple.com/forums/thread/737707 Bug: actions/runner-images#9273 Bug: Homebrew/homebrew-core#145991 Bug: https://stackoverflow.com/questions/78017671/runtime-issues-with-stdoptional-in-gcc-on-m2-mac

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

* chore: fix mac os ci Update the runner to macos 13 following this issue actions/runner-images#9997 --------- Signed-off-by: Roman Gershman <romange@gmail.com> Signed-off-by: Roman Gershman <roman@dragonflydb.io>

sureshe456 · 2024-07-05T14:58:38Z

Hi @EmilDohne - Please use macos-latest with xcode 15.3. In this setup it will work. We are closing the issue.Thanks.

EmilDohne · 2024-07-05T15:01:16Z

Thank you @sureshe456 , will do!

… as per actions/runner-images#9997

EmilDohne added bug report needs triage labels Jun 5, 2024

sergei-pyshnoi assigned erik-bershel and Alexey-Ayupov Jun 5, 2024

sergei-pyshnoi added Area: C/C++ OS: macOS and removed needs triage labels Jun 5, 2024

quentin mentioned this issue Jun 5, 2024

Apple ARM CI: use default toolchain, export SDKROOT souffle-lang/souffle#2491

Merged

EmilDohne mentioned this issue Jun 5, 2024

fix findLayerAs() function raising error when it should only raise a … EmilDohne/PhotoshopAPI#77

Merged

FeignClaims added a commit to FeignClaims/cpp_conan_template that referenced this issue Jun 7, 2024

fix(ci): Disable gcc-13 on macos for now

d723c8d

Util the sdk support is propagated to the runners, see actions/runner-images#9997

FeignClaims mentioned this issue Jun 10, 2024

fix: fix Hardening options and LTO for multi-configuration generators aminya/project_options#260

Merged

erik-bershel added bug Something isn't working external labels Jun 10, 2024

erik-bershel added the awaiting-deployment Code complete; awaiting deployment and/or deployment in progress label Jun 12, 2024

erik-bershel added investigate Collect additional information, like space on disk, other tool incompatibilities etc. and removed awaiting-deployment Code complete; awaiting deployment and/or deployment in progress labels Jun 14, 2024

hartwork mentioned this issue Jun 16, 2024

cmake.yml: Downgrade to GCC 12 for macOS 12 to fix CI rpodgorny/unionfs-fuse#147

Merged

thejohnfreeman added a commit to thejohnfreeman/autocheck that referenced this issue Jun 18, 2024

Fix workflow

9f4e4eb

actions/runner-images#9997 (comment)

thejohnfreeman added a commit to thejohnfreeman/autocheck that referenced this issue Jun 18, 2024

Fix workflow

7ee4218

actions/runner-images#9997 (comment)

Beanavil mentioned this issue Jun 19, 2024

fix CI failures KhronosGroup/OpenCL-Headers#254

Closed

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

e2b26d2

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

romange mentioned this issue Jun 27, 2024

chore: fix mac os ci romange/helio#286

Merged

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

7439e90

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

d754b9e

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

33f6843

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

c6c05d0

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

66fe2fe

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

9d9bb63

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

c8bd39c

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

4569cb4

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

romange added a commit to romange/helio that referenced this issue Jun 27, 2024

chore: fix mac os ci

cb19167

Update the runner to macos 13 following this issue actions/runner-images#9997 Signed-off-by: Roman Gershman <romange@gmail.com>

sureshe456 closed this as completed Jul 5, 2024

EmilDohne added a commit to EmilDohne/PhotoshopAPI that referenced this issue Jul 5, 2024

modify github actions runs to execute on macos-latest with xcode 15.3…

f71baa3

… as per actions/runner-images#9997

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MacOS {12-14} GCC build failures #9997

MacOS {12-14} GCC build failures #9997

EmilDohne commented Jun 5, 2024

quentin commented Jun 5, 2024

EmilDohne commented Jun 5, 2024

erik-bershel commented Jun 10, 2024

EmilDohne commented Jun 10, 2024

erik-bershel commented Jun 14, 2024

EmilDohne commented Jun 14, 2024

erik-bershel commented Jun 14, 2024

thejohnfreeman commented Jun 18, 2024

erik-bershel commented Jun 18, 2024

sureshe456 commented Jul 5, 2024

EmilDohne commented Jul 5, 2024

MacOS {12-14} GCC build failures #9997

MacOS {12-14} GCC build failures #9997

Comments

EmilDohne commented Jun 5, 2024

Description

Platforms affected

Runner images affected

Image version and build link

Is it regression?

Expected behavior

Actual behavior

Repro steps

quentin commented Jun 5, 2024

EmilDohne commented Jun 5, 2024

erik-bershel commented Jun 10, 2024

EmilDohne commented Jun 10, 2024

erik-bershel commented Jun 14, 2024

EmilDohne commented Jun 14, 2024

erik-bershel commented Jun 14, 2024

thejohnfreeman commented Jun 18, 2024

erik-bershel commented Jun 18, 2024

sureshe456 commented Jul 5, 2024

EmilDohne commented Jul 5, 2024