Cross-compile for androideabi on -msvc target fails

[vvanders]

error: failed to run custom build command for `backtrace-sys v0.1.10`
process didn't exit successfully: `...target\debug\build\backtrace-sys-0c4d13204b0e1510\build
-script-build` (exit code: 101)
--- stdout
OPT_LEVEL = Some("0")
TARGET = Some("armv7-linux-androideabi")
HOST = Some("x86_64-pc-windows-msvc")
TARGET = Some("armv7-linux-androideabi")
TARGET = Some("armv7-linux-androideabi")
HOST = Some("x86_64-pc-windows-msvc")
CC_armv7-linux-androideabi = None
CC_armv7_linux_androideabi = None
TARGET_CC = None
CC = None
TARGET = Some("armv7-linux-androideabi")
HOST = Some("x86_64-pc-windows-msvc")
CFLAGS_armv7-linux-androideabi = None
CFLAGS_armv7_linux_androideabi = None
TARGET_CFLAGS = None
CFLAGS = None
PROFILE = Some("debug")
running: "...\\.cargo\\registry\\src\\github.com-1ecc6299db9ec823\\backtrace-sys-0.1.10\\src/libbacktrace/c
onfigure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--target=armv7-linux-androideabi
" "--host=x86_64-pc-windows-msvc"

--- stderr
thread 'main' panicked at 'failed to get status: %1 is not a valid Win32 application. (os error 193)', ...\.c
argo\registry\src\github.com-1ecc6299db9ec823\backtrace-sys-0.1.10\build.rs:131
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Hitting this with some JNI libraries, not quite sure what the fix is here but happy to take a shot at it if I could get some pointers.

[vvanders]

Also happens on GNU, this looks like the offending SHA1: 390ea2a

Also the dependency that specified this(jni-rs) has 0.2.1 in the dependency chain but 0.1.10 somehow is getting pulled in.

[vvanders]

Looking at it a bit more jni-rs declares error-chain 0.5.0 which references backtrace 0.2.1 but I'm getting backtrace 0.2.3 in the Cargo.lock. Any idea why the versioning isn't working right here?

[alexcrichton]

Oh looks like we are trying to execute a shell script on Windows which doesn't work, we just need to do "sh configure" instead. Would you be willing to prep and test out a patch?

[JoeyAcc]

I can confirm this issue, at least for cross-compiling on windows 10 using the x86_64-unknown-linux-gnu target.
Since I need this bug fixed for work I'm willing to help any way I can.
So if there is please let me know :)

[vvanders]

Happy to test a patch, I was able to get the library building with this: vvanders@80294ba but I'm not sure if it functions yet since I hit something else gnarly.

Even when I load my new fix(+bump the cargo major version) I still get backtrace-sys pulled. we build the new major version but also this even though we never link it which means my main build still fails. If I understand what I was able to dig up with cargo right once we have a fix we need to do a few things:

• Release a new minor on the 0.2.x crate
• Release a new minor on the 0.3.x crate

As a side note, it would be really awesome if it were possible to pin a crate version in the Cargo.toml. I couldn't find a way to do it.

[alexcrichton]

@JoeyAcc ok hang on, looks like this is already a commit!

@vvanders and @JoeyAcc, can you test out the master branch of this repository? If that works I can certainly publish a new version

[vvanders]

Looks like no-go on stock windows. Is there a hard dependency on msys/cygwin? I'd really like to avoice that if possible(I used the library before without msys).

OPT_LEVEL = Some("0")
TARGET = Some("armv7-linux-androideabi")
HOST = Some("x86_64-pc-windows-msvc")
TARGET = Some("armv7-linux-androideabi")
TARGET = Some("armv7-linux-androideabi")
HOST = Some("x86_64-pc-windows-msvc")
CC_armv7-linux-androideabi = None
CC_armv7_linux_androideabi = None
TARGET_CC = None
CC = None
TARGET = Some("armv7-linux-androideabi")
HOST = Some("x86_64-pc-windows-msvc")
CFLAGS_armv7-linux-androideabi = None
CFLAGS_armv7_linux_androideabi = None
TARGET_CFLAGS = None
CFLAGS = None
PROFILE = Some("debug")
running: "sh" "C:\\dev\\backtrace-rs\\backtrace-sys\\src/libbacktrace/configure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--target=
armv7-linux-androideabi" "--host=x86_64-pc-windows-msvc"

--- stderr
thread 'main' panicked at '

failed to execute command: The system cannot find the file specified. (os error 2)
Is `sh` not installed?

', backtrace-sys\build.rs:128
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Build failed, waiting for other jobs to finish...
error: build failed

[alexcrichton]

Yes compiling libbacktrace requires some form of unix-like environment as AFAIK libbacktrace doesn't have an msvc-like build system.

You can turn off the dependency by disabling default features of this crate and selectively enabling strategies you'd like to use when generating a backtrace, more info can be found in the manifest

[vvanders]

Totally get how that could be a requirement for the latest version, I'm just trying to bring-up a project that used to compile on the 0.2.x series of crates. I'm actually pulling it in indirectly thought other dependencies so I'm not sure if I can actually configure the leaf dependency.

I just confirmed here locally that 0.2.1 build cleanly on msvc + androideabi and the commit I referenced in post #2 is the commit that seemed to break it. Would you consider the change in dependencies to be a break in the semver? Since downstream dependencies automatically uplevel on a minor version I don't have a way to specify the specific crate I consume without manually hacking my Cargo.lock which I'm hesitant to do.

[alexcrichton]

This crate unfortunately has a bit of a colorful history. The historical versions of this crate all used libbacktrace through the standard library. That is, it used the symbols from the standard library rather than compiling its own copy. That's because the standard library didn't properly hide the libbacktrace symbols from other object files or shared objects. That was fixed in rust-lang/rust#39252 which meant that this crate would no longer compile correctly in all situations because it could no longer use libbacktrace from libstd.

As a result the "regression" was actually a bug fix in that we started needing to compile libbacktrace. Compiling C code is always pretty tricky to get right (brings in more system dependencies) and tends to not work immediately out of the box.

Does that make sense?

[vvanders]

Oh totally makes sense, it's just from a functionality standpoint it seems like a breakage to have something that compiled before fail. Without a way to pin a specific crate it leaves users in a bad spot.

I managed to fork each of my dependencies and plumb through a set of feature flags so I'm unblocked. I understand if it's too core/complex dependency chain to fix. Just wanted to let you know it's definitely a pain point.

[JoeyAcc]

I had a dependency on v0.2 which I've now upgraded to the revision you mentioned here.

However I still get an error:

joey@DESKTOP-P4V3PIP MINGW64 ~/WebstormProjects/sbr-validate-npm/native (master)
$ cargo build --target=x86_64-unknown-linux-gnu --verbose
       Fresh glob v0.2.11
       Fresh unicode-segmentation v1.1.0
       Fresh serde v1.0.2
       Fresh neon-build v0.1.15
       Fresh cslice v0.2.0
       Fresh matches v0.1.4
       Fresh utf8-ranges v1.0.0
       Fresh rustc-demangle v0.1.4
       Fresh num-traits v0.1.37
       Fresh regex-syntax v0.4.0
       Fresh lazy_static v0.2.8
       Fresh unicode-normalization v0.1.4
   Compiling backtrace v0.3.0 (https://github.com/alexcrichton/backtrace-rs.git?rev=4477f2176af80eb9c624ce24fcfec7118ac9b867#4477f217)
       Fresh serde v0.9.15
       Fresh libc v0.2.22
       Fresh num-integer v0.1.34
       Fresh cfg-if v0.1.0
     Running `rustc --crate-name build_script_build 'C:\Users\Joey\.cargo\git\checkouts\backtrace-rs-6fa9e9266de164f1\4477f21\build.rs' --crate-type bin --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="libbacktrace"' --cfg 'feature="dbghelp"' --cfg 'feature="kernel32-sys"' --cfg 'feature="libunwind"' --cfg 'feature="dladdr"' --cfg 'feature="backtrace-sys"' --cfg 'feature="dbghelp-sys"' --cfg 'feature="winapi"' --cfg 'feature="coresymbolication"' -C metadata=65bac2c24596877e -C extra-filename=-65bac2c24596877e --out-dir 'C:\Users\Joey\WebstormProjects\sbr-validate-npm\native\target\debug\build\backtrace-65bac2c24596877e' -L 'dependency=C:\Users\Joey\WebstormProjects\sbr-validate-npm\native\target\debug\deps' --cap-lints allow`
       Fresh thread-id v3.0.0
       Fresh memchr v1.0.1
       Fresh time v0.1.37
       Fresh bitflags v0.7.0
       Fresh dtoa v0.4.1
       Fresh xml-rs v0.3.6
       Fresh xml-rs v0.4.1
       Fresh gcc v0.3.45
       Fresh xmltree v0.4.0
       Fresh either v1.1.0
   Compiling backtrace-sys v0.1.10 (https://github.com/alexcrichton/backtrace-rs.git?rev=4477f2176af80eb9c624ce24fcfec7118ac9b867#4477f217)
       Fresh aho-corasick v0.6.3
       Fresh void v1.0.2
       Fresh unicode-bidi v0.2.5
     Running `rustc --crate-name build_script_build 'C:\Users\Joey\.cargo\git\checkouts\backtrace-rs-6fa9e9266de164f1\4477f21\backtrace-sys\build.rs' --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=b6f4bfbcfd750d95 -C extra-filename=-b6f4bfbcfd750d95 --out-dir 'C:\Users\Joey\WebstormProjects\sbr-validate-npm\native\target\debug\build\backtrace-sys-b6f4bfbcfd750d95' -L 'dependency=C:\Users\Joey\WebstormProjects\sbr-validate-npm\native\target\debug\deps' --extern 'gcc=C:\Users\Joey\WebstormProjects\sbr-validate-npm\native\target\debug\deps\libgcc-c95fcb0f70a862e8.rlib' --cap-lints allow`
       Fresh unreachable v0.1.1
       Fresh idna v0.1.1
       Fresh thread_local v0.3.3
       Fresh url v1.4.0
       Fresh regex v0.2.1
       Fresh num-iter v0.1.33
       Fresh num v0.1.37
       Fresh rustc-serialize v0.3.24
       Fresh log v0.3.7
       Fresh itoa v0.3.1
       Fresh serde_json v0.9.10
       Fresh unicode-xid v0.0.4
       Fresh neon-runtime v0.1.15
       Fresh synom v0.11.3
       Fresh neon v0.1.15
       Fresh chrono v0.3.1
       Fresh quote v0.3.15
       Fresh serde v0.8.23
       Fresh syn v0.11.11
       Fresh serde_xml v0.9.1
       Fresh serde_codegen_internals v0.14.2
       Fresh url_serde v0.1.3
       Fresh serde_derive v0.9.15
       Fresh itertools v0.5.10
     Running `C:\Users\Joey\WebstormProjects\sbr-validate-npm\native\target\debug\build\backtrace-65bac2c24596877e\build-script-build`
     Running `C:\Users\Joey\WebstormProjects\sbr-validate-npm\native\target\debug\build\backtrace-sys-b6f4bfbcfd750d95\build-script-build`
error: failed to run custom build command for `backtrace-sys v0.1.10 (https://github.com/alexcrichton/backtrace-rs.git?rev=4477f2176af80eb9c624ce24fcfec7118ac9b867#4477f217)`
process didn't exit successfully: `C:\Users\Joey\WebstormProjects\sbr-validate-npm\native\target\debug\build\backtrace-sys-b6f4bfbcfd750d95\build-script-build` (exit code: 101)
--- stdout
OPT_LEVEL = Some("0")
TARGET = Some("x86_64-unknown-linux-gnu")
HOST = Some("x86_64-pc-windows-msvc")
TARGET = Some("x86_64-unknown-linux-gnu")
TARGET = Some("x86_64-unknown-linux-gnu")
HOST = Some("x86_64-pc-windows-msvc")
CC_x86_64-unknown-linux-gnu = None
CC_x86_64_unknown_linux_gnu = None
TARGET_CC = None
CC = Some("gcc")
TARGET = Some("x86_64-unknown-linux-gnu")
HOST = Some("x86_64-pc-windows-msvc")
CFLAGS_x86_64-unknown-linux-gnu = None
CFLAGS_x86_64_unknown_linux_gnu = None
TARGET_CFLAGS = None
CFLAGS = None
PROFILE = Some("debug")
running: "sh" "C:\\Users\\Joey\\.cargo\\git\\checkouts\\backtrace-rs-6fa9e9266de164f1\\4477f21\\backtrace-sys\\src/libbacktrace/configure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--target=x86_64-unknown-linux-gnu" "--host=x86_64-pc-windows-msvc"
checking build system type... x86_64-pc-mingw64
checking host system type...
--- stderr
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
Invalid configuration `x86_64-pc-windows-msvc': machine `x86_64-pc-windows' not recognized
configure: error: /bin/sh C:\Users\Joey\.cargo\git\checkouts\backtrace-rs-6fa9e9266de164f1\4477f21\backtrace-sys\src/libbacktrace/config.sub x86_64-pc-windows-msvc failed
thread 'main' panicked at 'failed with: exit code: 1', C:\Users\Joey\.cargo\git\checkouts\backtrace-rs-6fa9e9266de164f1\4477f21\backtrace-sys\build.rs:135
stack backtrace:
   0: std::sys_common::backtrace::_print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:94
   1: std::panicking::default_hook::{{closure}}
             at C:\projects\rust\src\libstd\panicking.rs:354
   2: std::panicking::default_hook
             at C:\projects\rust\src\libstd\panicking.rs:371
   3: std::panicking::rust_panic_with_hook
             at C:\projects\rust\src\libstd\panicking.rs:549
   4: std::panicking::begin_panic<collections::string::String>
             at C:\projects\rust\src\libstd\panicking.rs:511
   5: std::panicking::begin_panic_fmt
             at C:\projects\rust\src\libstd\panicking.rs:495
   6: build_script_build::run
             at .\build.rs:135
   7: build_script_build::main
             at .\build.rs:74
   8: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:98
   9: std::rt::lang_start
             at C:\projects\rust\src\libstd\rt.rs:51
  10: main
  11: __scrt_common_main_seh
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  12: BaseThreadInitThunk

However, I am not sure what causes this new issue, but this part does look weird to me:

https://github.com/alexcrichton/backtrace-rs.git?rev=4477f2176af80eb9c624ce24fcfec7118ac9b867#4477f217

If the revision is being passed as a URL argument, what is the purpose of the #4477f217 identifier?

[alexcrichton]

Ok thanks for the heads up @vvanders always good to be aware of this!

It may be a plausible strategy here to just auto-disable libbacktrace if it fails to compile? That'd at least restore compilation and just use a different strategy for generating backtraces. Either that or libbacktrace could just get disabled on Android entirely if it's not too useful anyway.

@JoeyAcc it looks like you're trying to cross-compile from Windows to Linux, but that typically doesn't work for a number of reasons? Has that worked for you in the past?

[JoeyAcc]

No it never has, I was actually just trying out the cross-compiling guides* here and here to see if it could work at all. It was during that process that I encountered all this.

*Being able to cross-compile between Windows and Linux/OS X would be very useful to me.

[alusch]

I've been cross-compiling successfully from Windows to Linux (Raspberry Pi) using the toolchain from http://gnutoolchains.com/raspberry, but I'm now running into the same error as @JoeyAcc when using the error-chain crate.

For now I'm just disabling backtrace support entirely in error-chain, but that's not really ideal as my project is a library. As far as I can tell, there isn't a way to set dependencies for certain host/target cross compilation pairs in Cargo.toml, right? I suppose I could add a feature to my library to make it the caller's decision, though that's still not ideal.

Would it be possible to teach the configure script about x86_64-pc-windows and have it handle this case gracefully (even just doing a no-op)?