Compilation error only occurs with Neon on Rust 1.26


I have a problem compiling a C++ library dependency, croaring-rs, but only with Neon on OS X on Rust 1.26.
The relevant error is:

process didn't exit successfully: `/Users/dev/work/reproducible-reports/8-neon-roaring-rust26/native/target/release/build/croaring-sys-cc20bb91cebf5e62/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)

I’ve tested all eight combinations of:

  • Rust 1.26 vs. 1.25
  • OS X vs. Ubuntu
  • Neon vs. running cargo test in croaring-rs

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.)

I’d love if someone can check my notes and see they can reproduce:

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.


Try appending this to your Cargo.toml:

# TODO: Enabling LTO is intended a temporary workaround for the bug
# described @
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 added it to the Cargo.toml of the neon extension:

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.