"extern location for serde_derive is of an unknown type" when cross compiling

[plietar]

Trying to cross compile serde's example from macOS to Linux

$ cargo build --features "unstable" --target arm-unknown-linux-gnueabihf
   Compiling serde-syntex-example v0.1.0 (file:///private/tmp/serde/examples/serde-syntex-example)
error: extern location for serde_derive is of an unknown type: /private/tmp/serde/examples/serde-syntex-example/target/debug/deps/libserde_derive-c68a89b9da8abb52.dylib
  |
  = help: file name should be lib*.rlib or lib*..so

error: aborting due to previous error

error: Could not compile `serde-syntex-example`.

To learn more, run the command again with --verbose.

Meta

rustc --version --verbose:

rustc 1.15.0-nightly (ac635aa95 2016-11-18)
binary: rustc
commit-hash: ac635aa95ba851898e125b047ad7b8d6a8fecf8e
commit-date: 2016-11-18
host: x86_64-apple-darwin
release: 1.15.0-nightly
LLVM version: 3.9

[alexcrichton]

cc @jseyfried

I'm not sure if this ever worked, but maybe you know if something changed recently about it? (or maybe was fixed)

[keeperofdakeys]

Could this be the same issue as #37893?

[jseyfried]

I believe this was fixed by #37893.
@plietar could you verify that this is no longer a problem with the latest nightly (2016-11-22)?

[plietar]

Nope, same error with 2016-11-22

[plietar]

Interestingly, renaming the file from .so to .dylib just to make the path name validation code happy ends up with rustc complaining it's not a .dylib :

error: extern location for serde_derive is of an unknown type: /private/tmp/serde/examples/serde-syntex-example/target/debug/deps/libserde_derive-4843951d18ee9e5a.so
  |
  = help: file name should be lib*.rlib or lib*..dylib

[plietar]

Been looking into it, AFAIU, the crate loader first tries to load the file for the target, which naturally fails with the error, and then tries again with the host triple which actually succeeds.

However because the first attempt raised an error, the compiler eventually stops on the next abort_if_errors.

I guess the solution would be to save the error, and only raise it if report_errs is called.

I'd be happy to give it a try at fixing it, probably tomorrow

[jseyfried]

@plietar great, thanks for diagnosing! If you'd like to work on fixing, free to ping me on IRC with questions (or ask here). Otherwise, I can fix tomorrow.