Rustc doesn't link c++ std lib

[shayanjm]

I am currently trying to work with https://github.com/flier/rust-hyperscan. I recently updated cargo via rustup and started noticing that my code breaks when run.

I am currently running MacOS 10.12.6 and rustc 1.20.0

This is a contrived example, mostly from the upstream "rust-hyperscan" project, which includes the output error I'm seeing when I runcargo clean && cargo test: https://gist.github.com/shayanjm/aa7a9ebb0bddd1beb8ec4f3d3f87463b

On L80 of build.rs (https://gist.github.com/shayanjm/aa7a9ebb0bddd1beb8ec4f3d3f87463b#file-build-rs-L80) I've verified that the println! runs as expected by changing c++ to something I know would break and retrying cargo clean && cargo test.

I've also verified that libc++ has the symbols in question via nm -gU /usr/lib/libc++dylib | grep dynamic, which returned 0000000000018c54 I ___dynamic_cast (the first "undefined symbol" in the error)

Is this an issue with the way rustc is linking the c++ std lib? Or have I done something wrong?

[steveklabnik]

This doesn't feel like a rustc bug to me, or at least, there's too much going on here to really determine it. As such, I would suggest posting to https://users.rust-lang.org/, which is better for these kinds of questions. We try to keep the issue tracker for bugs only.

If you can reduce this to a small example demonstrating that it's a rustc bug, then we can re-open, but until then, I'm going to give this a close. Thank you!

[valpackett]

Maybe this isn't the problem on your machine, but in the build.rs script, libc++ must be printed last. It's a really weird issue, I've just encountered this while fixing mozjs to build on FreeBSD. Somehow no one encountered it with mozjs on other platforms o_0 But this is mentioned in a ton of StackOverflow answers about C++ linking problems (without Rust!).

Trying to build rust-hyperscan on FreeBSD (after fixing build.rs):

note: /usr/bin/ld: /usr/home/greg/src/github.com/flier/rust-hyperscan/target/debug/deps/libhyperscan-9d582c0a3986e7c0.rlib(runtime.c.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
          /usr/home/greg/src/github.com/flier/rust-hyperscan/target/debug/deps/libhyperscan-9d582c0a3986e7c0.rlib: could not read symbols: Bad value
          cc: error: linker command failed with exit code 1 (use -v to see invocation)

— fixed that by, well, recompiling the system hyperscan with -fPIC :)

[shayanjm]

@myfreeweb unfortunately this didn't fix the build on my machine :(

[retep998]

Based on a conversation on IRC, it appears this issue was resolved by switching from kind=static to kind=dylib. Really this is just yet another reason we should either change the behavior of kind=static or stabilize kind=static-nobundle and heavily deprecate kind=static.

[shayanjm]

@retep998 +1 - I'll also be creating a PR to the upstream rust-hyperscan project to fix this. Thanks everyone for your help!