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.


#6

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.