Linking issue with Rust 1.37.0

[vitvakatu]

See build log.

It looks like name mangling doesn't work correctly when linking with a dynamic library which is also depends on libstd.

The application structure is the following:

1. Large dylib crate java_bindings, containing 400+ dependencies and is dynamically linked to libstd.dylib.
2. exonum-java binary application, depends on java_bindings and is dynamically linked to libstd.dylib.

The compilation works well on Rust 1.36.0, but doesn't work on 1.37.0 and nightly versions (such as rustc 1.39.0-nightly (c6e9c76c5 2019-09-04)).

To reproduce:

git clone https://github.com/exonum/exonum-java-binding
cd exonum-java-binding/exonum-java-binding/core/rust/exonum-java
rustup default nightly
cargo build

Sorry for such heavy project, couldn't reproduce on an easier example.

[popzxc]

This bug is can also be reproduced with a small project: link (be sure to use a linked revision, since project is under active development, and upstream may change).

If I try to compile examples/node with 1.38.0, I get errors similar to the listed in the issue.
With 1.36.0 everything works fine.

[alexkornitzer]

Just finished bisecting and the culprit commit affecting my project is 185dceb which appears to be the same changes affecting #66265 and #65610. @alexcrichton is there any chance we can revert this? or is there a way to move this issue forwards?

[alexcrichton]

Sorry I don't know much about that change, I didn't author it, I'd recommend bringing it up on the PR and/or with the release team to figure out a revert.

[alexkornitzer]

Thank you, appologies for incorrectly @'ing you, I shall do just that.

[michaelwoerister]

Is there are strong reason for using Rust dylibs instead of rlibs or cdylibs for these projects? Rust dylibs are rather underspecified and the concrete set of symbols exported from them is an implementation detail.

[popzxc]

Yes, if the built library should be usable by both Rust and other programming language.

[alexkornitzer]

@michaelwoerister so I need to use dylibs over rlibs and cdylibs for a couple of reasons:

1. Can't use rlibs as they are statically linked and this takes too much space especially as I use a plugin system and hence have a shared library of common code.
2. From what I understand I cannot use cdylibs because I need to expose rust primitives such as traits, etc. and these cannot be exposed through a C ABI. (I also acknowledge that plugins are limited due to lack of a stable dylib abi but I am happy with that limit atm)

Very happy to be corrected if any of the above is incorrect.

[michaelwoerister]

@alexkornitzer It sounds like your project should not be affected by the PR in question. Can you share a reproduction?

[alexkornitzer]

@michaelwoerister annoyingly it is private code, let me see if I can reproduce it in a generic project.

[vitvakatu]

Btw, we can confirm that reverting the PR in question with locally build Rust compiler solves the problem on Rust 1.37 and Rust 1.39.

cc @skletsun

[alexkornitzer]

@michaelwoerister here is a relatively streamlined build that will cause linker errors. Commenting out the Consul crate (https://github.com/AlexKornitzer/dylib-errors/blob/1ab7cdbddebec3353a80a40d7b8ae0899f6ac581/shared/src/lib.rs#L2) will cause the majority of the errors to go away (no idea why!), I believe the NNG errors are due to related C issues, but am unsure. I will make a branch without NNG and see if the ones caused by Consul go away.

The below builds on 1.36.0 but not above:
https://github.com/AlexKornitzer/dylib-errors

Build output:
https://gist.github.com/AlexKornitzer/0f56318716048b992e6ac61f8e2992da