miri: Cannot build "backtrace" with locally-compiled rustc on macOS: expected enum `std::os::raw::c_void`, found enum `libc::c_void`
I locally built rustc master and linked stage2 using rustup, set the override in the miri subdir, but I’m getting this when running cargo build:
$ cargo build
Compiling backtrace v0.3.29
Compiling serde v1.0.92
error[E0308]: mismatched types
--> /Users/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/symbolize/coresymbolication.rs:155:32
|
155 | self.dll = libc::dlopen(lib.as_ptr() as *const _, libc::RTLD_LAZY);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `std::os::raw::c_void`, found enum `libc::c_void`
...
186 | / coresymbolication! {
187 | | #[load_path = "/System/Library/PrivateFrameworks/CoreSymbolication.framework\
188 | | /Versions/A/CoreSymbolication"]
189 | | extern "C" {
... |
202 | | }
203 | | }
| |_- in this macro invocation
|
= note: expected type `*mut std::os::raw::c_void`
found type `*mut libc::c_void`
error[E0308]: mismatched types
--> /Users/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/symbolize/coresymbolication.rs:176:39
|
176 | match libc::dlsym(self.dll, symbol.as_ptr() as *const _) as usize {
| ^^^^^^^^ expected enum `libc::c_void`, found enum `std::os::raw::c_void`
...
186 | / coresymbolication! {
187 | | #[load_path = "/System/Library/PrivateFrameworks/CoreSymbolication.framework\
188 | | /Versions/A/CoreSymbolication"]
189 | | extern "C" {
... |
202 | | }
203 | | }
| |_- in this macro invocation
|
= note: expected type `*mut libc::c_void`
found type `*mut std::os::raw::c_void`
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0308`.
error: Could not compile `backtrace`.
warning: build failed, waiting for other jobs to finish...
Note that ./x.py build src/tools/miri works just fine.
I’ve discussed this a bit with @RalfJung on chat but not had much luck, so I thought I’d post it here so we can treat it as a proper issue.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 30 (29 by maintainers)
I’m on macos, so I don’t think that’s the issue. Did you run
cargo clean? The only thing I can think of is if there were old artifacts in thetargetdirectory that were linked against an older version of libstd (which cargo doesn’t track).Also, the reason
cargo update -p backtracedoesn’t do anything in the rust repo is because libstd specifies some features that only exist in 0.3.29 and cargo won’t update to a newer version that is missing those features (0.3.30 doesn’t have therustc-dep-of-stdfeature). It should probably print a note why it can’t update.