Open Masber opened 8 months ago
cc @BlackHoleFox seems a bit similar to #963
Edit:
The runner information from CI log:
Image: macos-11 Version: 20240127.1 Included Software: https://github.com/actions/runner-images/blob/macOS-11/20240127.1/images/macos/macos-11-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macOS-11%2F20240127.1
It uses clang 13.0.0 by default and has clang 15 available in homebrew
I had a very similar issue trying to compile a project on my Mac. I have two projects using the tmq library. I spent the whole weekend trying to figure out why the project I started on friday didn't compile (showing up a lot of messages quite similar to the ones you showed), but another one with exact same dependencies coded on last month was compiling as a charm. At first I thought this might be a problem with the lib itself (all the problems started when I added this dependency to my project), but only when I piped the 4k lines of error messages to a text file that I realized the potential issue was on linking process (the error messages was flooding my terminal so I was unable to check the whole message).
Since the dependencies in my Cargo.toml
file did not differ between both projects, I had to find the culprit in Cargo.lock
. My very first suspect was the cc
, and to fix the compilation issues I had to commit a crime: I manually changed the cc package description in the Cargo.lock
file, as follow:
Before:
[[package]]
name = "cc"
version = "1.0.88"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "02f341c093d19155a6e41631ce5971aac4e9a868262212153124c15fa22d1cdc"
dependencies = [
...
]
After:
[[package]]
name = "cc"
version = "1.0.83"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f1174fb0b6ec23863f8b971027804a42614e347eafb0a95bf0b12cdae21fc4d0"
dependencies = [
...
]
The version "1.0.83" was taken from the Cargo.toml
of my other project that was the same dependencies but was compiling.
Well, I really don't know how this "version downgrading" might affect the code (mine or yours), but this was the only way I found to solve this (at least for now). I hope that soon a patch could fix this, or maybe a more "ergonomic way" to manage this "internal" dependencies may help (frankly speaking, I don't know exactly how Cargo handles '.lock' files).
https://github.com/eth-cscs/manta/actions/runs/8111755111/job/22171593499
The error in the output seems to be different from what you pasted, it seems to be #962
Instead of manually changing Cargo.lock
you can do cargo update -p cc --precise 1.0.83
.
Guys, can you please confirm you have same issues with the most recent version of this library?
I was seeing this issue with 1.0.99 when cross compiling for macos using osxcross. I solved it by setting the CC
, CXX
etc environment variables correctly for cross compiling. This may be of use to someone.
Confirming that this is still an issue. We're not even using macos, we're compiling for x86_64-fortanix-unknown-sgx
. Unfortunately we now have to bump cc
because of other reasons, and it's difficult to drill down to find the issue.
Dear CC community,
I am having the following error when creating apple artifacs
https://github.com/eth-cscs/manta/actions/runs/8111755111/job/22171593499
I also tried locally using the
cross
crate but it also failsI raised this issue with opessl and they refered me to you.
Could you please advice what do I need to do in order to build apple artifacts?
thank you very much