Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

debugging the macos-13 github runner workflow #387

Open
AngieHinrichs opened this issue Dec 4, 2024 · 0 comments
Open

debugging the macos-13 github runner workflow #387

AngieHinrichs opened this issue Dec 4, 2024 · 0 comments

Comments

@AngieHinrichs
Copy link
Contributor

@yatisht we need to get usher compiling on Mac again, not only the old x86_64 macs but also the new arm64 macs. To that end I'm trying to get the macOS-13 github workflow job to run successfully on my fork, AngieHinrichs/usher. The macos-13 runner is x86_64, and I expect that to be easier (closer to the linux builds that are working) than arm64 but it's not quite working yet.

I've worked around two errors so far in my fork:

  • ripples-fast won't compile with the Clang compiler because it uses GNU x86 Built-in Functions, so skip it for now (in install/installMacOS.sh) and build all the other executables.
  • mutation_detailed.proto has a message named target, but code generated by newer versions of protobuf/protoc (such as the versions available in homebrew) uses the symbol target for its own purposes (!) and that makes a conflict, so the generated code failed to compile. I renamed the message to place_target (to match the name of the array of such messages, place_targets). Fortunately the usher-sampled code is written in such a way that I didn't have to change any other code, just the .proto.

Now I'm running into an error that is more confusing and I hope you can help. When compiling matOptimize/main.cpp, it stops at this error:
https://github.com/AngieHinrichs/usher/actions/runs/12150323931/job/33882851978#step:3:2289

/Users/runner/work/usher/usher/src/matOptimize/main.cpp:249:23: error: no type named 'filesystem_error' in namespace 'boost::filesystem'; did you mean 'std::filesystem::filesystem_error'?
        } catch(const boost::filesystem::filesystem_error& ex) {
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                      std::filesystem::filesystem_error

-- it's complaining that boost::filesystem::filesystem_error does not exist. As far as I can tell, brew is installing Boost version 1.86.0.2, and the boost::filesystem documentation for 1.86.0 still lists Class filesystem_error just like the documentation for older versions.

Any idea why the compiler can find boost::filesystem but not boost::filesystem::filesystem_error? Or suggestions for things I can add to installMacOS.sh to debug? Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant