and this error only comes up for Neon on OS X with Rust 1.26.
Not sure what else to try, since I'm not super familiar w/ how Rust interops with C (and the details of C libraries and unix memory stuff in general; for what it's worth, I've also tried upgrading bindgen to the latest version within croaring-rs, but it had no effect.)
In particular, I'm curious if the issue is related to my old version of OS X.
So if you are on something newer than 10.9.5 and have a minute, please clone my example and see if it compiles for you.
[profile.release]
# TODO: Enabling LTO is intended a temporary workaround for the bug
# described @ https://github.com/rust-lang/rust/issues/50586
lto = true
and then rebuild the code with cargo build --release. If that works you've been hit by the same bug as I have.
Appreciate the quick reply @jjpe, unfortunately enabling lto did not appear to resolve the issue.
Not sure if it makes a difference, but based on my quick read of that github issue, it seems like that issue occurs at runtime, whereas mine occurs at compile time.
Technically the issue I referred to is a link-time bug that manifests itself during runtime, which is why using LTO (link-time optimization) works there.
Just to doublecheck: Did you make the additions to the Cargo.toml of the top-level project, i.e. the crate that generates the binary? If you're doing it in a dependency then I don't think this will work in any case.
I'm not sure if this is the most "top level" place I can put something, or if Neon has an implicit toplevel Cargo.toml hidden within its special compilation mechanics.
Just for future reference in case anyone finds this thread: I never found the root cause of this problem. But after stepping away for three months, we're now at Rust 1.29 and that compiles everything just fine, so whatever issue introduced in 1.26 must have been fixed.