Compilation error only occurs with Neon on Rust 1.26


#1

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: https://github.com/lynaghk/reproducible-reports/tree/master/8-neon-roaring-rust26

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.


#2

Try appending this to your Cargo.toml:

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


#3

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.


#4

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.


#5

I added it to the Cargo.toml of the neon extension: https://github.com/lynaghk/reproducible-reports/blob/fc59b577fb725d578da53d86c46da7aa7048d07a/8-neon-roaring-rust26/native/Cargo.toml

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.