libffi-rs
libffi-rs copied to clipboard
tov
libffi-sys refuses to build with gnu toolchain on Windows
Compiling libffi-sys v1.1.0
Running `<MY_RUST_PROJECT_PATH>\target\release\build\libffi-sys-bcfb47f615dc8bff\build-script-build`
error: failed to run custom build command for `libffi-sys v1.1.0`
Caused by:
process didn't exit successfully: `<MY_RUST_PROJECT_PATH>\target\release\build\libffi-sys-bcfb47f615dc8bff\build-script-build` (exit code:101)
--- stderr
thread 'main' panicked at 'Copying libffi into the build directory: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }', <...>\rust-lang\.cargo\registry\src\github.com-1285ae84e5963aae\libffi-sys-1.1.0\build\common.rs:8:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
This looks similar to this issue: https://github.com/tov/libffi-sys-rs/issues/16
Shell command:
$> cargo +nightly-i686-pc-windows-gnu build --release --verbose --all --jobs 1 --target i686-pc-windows-gnu
My setup:
$> cargo -Vv
cargo 1.51.0 (43b129a20 2021-03-16)
release: 1.51.0
commit-hash: 43b129a20fbf1ede0df411396ccf0c024bf34134
commit-date: 2021-03-16
$> rustc -Vv
rustc 1.51.0 (2fd73fabe 2021-03-23)
binary: rustc
commit-hash: 2fd73fabe469357a12c2c974c140f67e7cdd76d0
commit-date: 2021-03-23
host: x86_64-pc-windows-gnu
release: 1.51.0
LLVM version: 11.0.1
GCC version:
gcc (i686-win32-dwarf-rev0, Built by MinGW-W64 project) 8.1.0
i686-8.1.0-win32-dwarf-rt_v6-rev0
@cher-nov Could you re-run the command with RUST_BACKTRACE=1 set? That may help determining what step exactly fails.
I suspect it's due to the custom target being specified, IIRC libffi uses slightly different names for some of them, but I'm not certain if that's the case here.
@cher-nov Could you re-run the command with
RUST_BACKTRACE=1set?
Sure.
RUST_BACKTRACE=1
Compiling libffi-sys v1.1.0
Running `<MY_RUST_PROJECT_PATH>\target\release\build\libffi-sys-bcfb47f615dc8bff\build-script-build`
error: failed to run custom build command for `libffi-sys v1.1.0`
Caused by:
process didn't exit successfully: `<MY_RUST_PROJECT_PATH>\target\release\build\libffi-sys-bcfb47f615dc8bff\build-script-build` (exit code:101)
--- stderr
thread 'main' panicked at 'Copying libffi into the build directory: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }', <...>\rust-lang\.cargo\registry\src\github.com-1285ae84e5963aae\libffi-sys-1.1.0\build\common.rs:8:26
stack backtrace:
0: rust_begin_unwind
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/panicking.rs:493:5
1: core::panicking::panic_fmt
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\core\src/panicking.rs:92:14
2: core::option::expect_none_failed
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\core\src/option.rs:1329:5
3: core::result::Result<T,E>::expect
4: build_script_build::common::run_command
5: build_script_build::not_msvc::build_and_link
6: build_script_build::main
7: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
RUST_BACKTRACE=full
Compiling libffi-sys v1.1.0
Running `<MY_RUST_PROJECT_PATH>\target\release\build\libffi-sys-bcfb47f615dc8bff\build-script-build`
error: failed to run custom build command for `libffi-sys v1.1.0`
Caused by:
process didn't exit successfully: `<MY_RUST_PROJECT_PATH>\target\release\build\libffi-sys-bcfb47f615dc8bff\build-script-build` (exit code:101)
--- stderr
thread 'main' panicked at 'Copying libffi into the build directory: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }', <...>\rust-lang\.cargo\registry\src\github.com-1285ae84e5963aae\libffi-sys-1.1.0\build\common.rs:8:26
stack backtrace:
0: 0x49d94c - core::fmt::write::h45d755886b411a7f
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\core\src\fmt/mod.rs:1092:17
1: 0x433df5 - std::io::Write::write_fmt::h50f1ae2e2b5af5a5
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src\io/mod.rs:1572:15
2: 0x441f06 - std::sys_common::backtrace::_print::h6f45af8a3a49fb2b
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src\sys_common/backtrace.rs:49:5
3: 0x441f06 - std::sys_common::backtrace::print::h3349ab0ff253cbcb
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src\sys_common/backtrace.rs:36:9
4: 0x441f06 - std::panicking::default_hook::{{closure}}::h80d289dc75de3eac
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/panicking.rs:208:50
5: 0x441b6a - std::panicking::default_hook::h011eecf8cd077bb8
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/panicking.rs:225:9
6: 0x4425d9 - std::panicking::rust_panic_with_hook::he132815485403a02
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/panicking.rs:591:17
7: 0x442221 - std::panicking::begin_panic_handler::{{closure}}::h1ffe0aa8bb6b2211
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/panicking.rs:497:13
8: 0x43f97d - std::sys_common::backtrace::__rust_end_short_backtrace::h9a1d800141b9d571
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src\sys_common/backtrace.rs:141:18
9: 0x442193 - rust_begin_unwind
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/panicking.rs:493:5
10: 0x499fd9 - core::panicking::panic_fmt::hc659c839484d8b17
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\core\src/panicking.rs:92:14
11: 0x499cd9 - core::option::expect_none_failed::h1d03a3c6f83f5ef5
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\core\src/option.rs:1329:5
12: 0x40a49b - core::result::Result<T,E>::expect::hfd77310ed7808ebf
13: 0x4048a8 - build_script_build::common::run_command::h7ed65e0df45acd13
14: 0x40b722 - build_script_build::not_msvc::build_and_link::hecd7ce69742a0ea3
15: 0x407e98 - build_script_build::main::h44527b5110fc88ee
16: 0x403b79 - core::ops::function::FnOnce::call_once::h9c8ac8cc0ab270d2
17: 0x405581 - std::sys_common::backtrace::__rust_begin_short_backtrace::h2e450a038ec305be
18: 0x409433 - std::rt::lang_start::{{closure}}::h3e783aadfcea1a8a
19: 0x442808 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h2865305cb22c3481
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\library\core\src\ops/function.rs:259:13
20: 0x442808 - std::panicking::try::do_call::h4df39ca3691a3422
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/panicking.rs:379:40
21: 0x442808 - std::panicking::try::h614371d718617389
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/panicking.rs:343:19
22: 0x442808 - std::panic::catch_unwind::ha3f10f4df56e4864
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/panic.rs:431:14
23: 0x442808 - std::rt::lang_start_internal::h9eb8338eb9035461
at /rustc/f5f33ec0e0455eefa72fc5567eb1280a4d5ee206\/library\std\src/rt.rs:51:25
24: 0x40940d - std::rt::lang_start::h35f31df2ec200e9a
25: 0x407ed3 - _main
26: 0x40138b - ___tmainCRTStartup
27: 0x760b343d - <unknown>
28: 0x77529812 - <unknown>
29: 0x775297e5 - <unknown>
@cher-nov It looks like the build script is running the build process for Unix systems. If you're not running inside something like MSYS2, that won't work. In this case it's failing because (I'm guessing) it can't find the cp command. I'm guessing this is because you're using cargo +nightly-i686-pc-windows-gnu, which results in target_env not being set to msvc, resulting in the build script failing as it does above.
In short, I don't think you can build libffi-rs using a GNU style Rust build while running inside a regular Windows/MSVC environment. Either you have to use a GNU style Rust build inside a Linux-like environment (e.g. MSYS2), or use an MSVC Rust build inside an MSVC environment. I'm not sure if there's a way we can support mixing the two.
Well, then support for the GNU style Rust on Windows in this crate would be very nice, I believe. You can consider it as a feature request. :)
@cher-nov Support for it would indeed be nice. Unfortunately, I'm not familiar enough with Windows to actually implement it :/
If using \usr\bin from Git for Windows installation folder, which contains some bits of coreutils including the cp utility, then it fails with another error:
$> set PATH="C:\Program Files\Git\usr\bin";%PATH%
$> set RUST_BACKTRACE=full
$> cargo +nightly build --target=i686-pc-windows-gnu --jobs 1 --verbose --all
Compiling libffi-sys v1.1.1
Running `<MY_RUST_PROJECT_PATH>\target\debug\build\libffi-sys-33e772ea77311f3b\build-script-build`
error: failed to run custom build command for `libffi-sys v1.1.1`
Caused by:
process didn't exit successfully: `<MY_RUST_PROJECT_PATH>\target\debug\build\libffi-sys-33e772ea77311f3b\build-script-build` (exit code: 101)
--- stderr
autogen.sh: line 2: exec: autoreconf: not found
thread 'main' panicked at 'Generating configure', <...>\rust-lang\.cargo\registry\src\github.com-1ecc6299db9ec823\libffi-sys-1.1.1\build\common.rs:8:5
stack backtrace:
0: 0x43f7ab - std::backtrace_rs::backtrace::dbghelp::trace::hebd11b225b5f28bf
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src\..\..\backtrace\src\backtrace/dbghelp.rs:98:5
1: 0x43f7ab - std::backtrace_rs::backtrace::trace_unsynchronized::h1b8b137891cb3a95
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src\..\..\backtrace\src\backtrace/mod.rs:66:5
2: 0x43f7ab - std::sys_common::backtrace::_print_fmt::h6c6d4d830d8b6265
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src\sys_common/backtrace.rs:67:5
3: 0x43f7ab - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h8ed754dab6c10796
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src\sys_common/backtrace.rs:46:22
4: 0x4a92fa - core::fmt::write::hc5ea6ea83086129b
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\core\src\fmt/mod.rs:1110:17
5: 0x432982 - std::io::Write::write_fmt::h4b25832ee2466f6b
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src\io/mod.rs:1588:15
6: 0x443410 - std::sys_common::backtrace::_print::h0afdd3d6700e4a72
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src\sys_common/backtrace.rs:49:5
7: 0x443410 - std::sys_common::backtrace::print::h6cc9cca470e70206
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src\sys_common/backtrace.rs:36:9
8: 0x443410 - std::panicking::default_hook::{{closure}}::hdea900a8fcd7d1a0
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/panicking.rs:208:50
9: 0x442fc4 - std::panicking::default_hook::h2b10cc1280948111
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/panicking.rs:225:9
10: 0x443b85 - std::panicking::rust_panic_with_hook::h2d579876e65be76b
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/panicking.rs:622:17
11: 0x4437c9 - std::panicking::begin_panic_handler::{{closure}}::h0bb2553d77f59f04
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/panicking.rs:519:13
12: 0x44019f - std::sys_common::backtrace::__rust_end_short_backtrace::h0e94d11a0572b51f
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src\sys_common/backtrace.rs:141:18
13: 0x443729 - rust_begin_unwind
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/panicking.rs:515:5
14: 0x4436dc - std::panicking::begin_panic_fmt::h23de7ee8c3522530
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/panicking.rs:457:5
15: 0x40480b - build_script_build::common::run_command::hf376ac9835a660f7
at <...>\rust-lang\.cargo\registry\src\github.com-1ecc6299db9ec823\libffi-sys-1.1.1/<...>\rust-lang\.cargo\registry\src\github.com-1ecc6299db9ec823\libffi-sys-1.1.1\build/common.rs:8:5
16: 0x40e0e7 - build_script_build::not_msvc::autogen::h85371b3071953cc8
at <...>\rust-lang\.cargo\registry\src\github.com-1ecc6299db9ec823\libffi-sys-1.1.1/<...>\rust-lang\.cargo\registry\src\github.com-1ecc6299db9ec823\libffi-sys-1.1.1\build/not_msvc.rs:111:5
17: 0x40d4e8 - build_script_build::not_msvc::build_and_link::h4d3f894b5f19a8a1
at <...>\rust-lang\.cargo\registry\src\github.com-1ecc6299db9ec823\libffi-sys-1.1.1/<...>\rust-lang\.cargo\registry\src\github.com-1ecc6299db9ec823\libffi-sys-1.1.1\build/not_msvc.rs:25:5
18: 0x40bca9 - build_script_build::main::he2cd94afdeade2a8
at <...>\rust-lang\.cargo\registry\src\github.com-1ecc6299db9ec823\libffi-sys-1.1.1/<...>\rust-lang\.cargo\registry\src\github.com-1ecc6299db9ec823\libffi-sys-1.1.1\build/build.rs:16:9
19: 0x4050ab - core::ops::function::FnOnce::call_once::he1987f806fad615d
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\library\core\src\ops/function.rs:227:5
20: 0x4071de - std::sys_common::backtrace::__rust_begin_short_backtrace::h2f02d27f7438f027
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\library\std\src\sys_common/backtrace.rs:125:18
21: 0x40b181 - std::rt::lang_start::{{closure}}::h4ea01d9800778be3
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\library\std\src/rt.rs:49:18
22: 0x443fef - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h7cdffb37b47f9ec7
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\library\core\src\ops/function.rs:259:13
23: 0x443fef - std::panicking::try::do_call::hd47cf9f3135aee1a
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/panicking.rs:401:40
24: 0x443fef - std::panicking::try::h5ced30deeb1c85b1
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/panicking.rs:365:19
25: 0x443fef - std::panic::catch_unwind::h30f61ae6d8f1ad0a
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/panic.rs:433:14
26: 0x443fef - std::rt::lang_start_internal::h645c8fd9187892d2
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\/library\std\src/rt.rs:34:21
27: 0x40b15f - std::rt::lang_start::h5cdb4cbd21ed3bd4
at /rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904\library\std\src/rt.rs:48:5
28: 0x40bcdc - main
29: 0x4013c7 - __tmainCRTStartup
30: 0x4014fb - mainCRTStartup
31: 0x7795556d - <unknown>
32: 0x77ab372d - <unknown>
Thus, it seems the only proper option to operate with Rust's GNU toolchain on Windows is by using the MSYS2 environment. I always wanted to avoid that because I prefer to use native tools where possible and separate installations of Git and mingw-w64, but unfortunately there's no other way at least for now.
@cher-nov You should be able to use libffi-rs just fine under a proper vistual studio setup. I've been using it there successfully without trouble.
Where things can go wrong is when you start mixing regular Windows tools and GNU tools. For example, if you use the Rust GNU toolchain then IIRC you also must run inside MSYS2 or similar; otherwise the build script and/or libffi itself get confused. Similarly, if you use a Vistual Studio toolchain inside MSYS2 or similar, I think Rust ends up using the wrong linker (at least I remember running into something like that).
Unfortunately, I never figured out how to solve these issues :confused:
@cher-nov You should be able to use libffi-rs just fine under a proper vistual studio setup. I've been using it there successfully without trouble.
Of course, but that's definitely what I'm trying to avoid as I don't like MSVC. :) I posted a MSYS2 mention just to let others know how to deal with such situation.
I believe this is related to the issues we're seeing in https://github.com/rust-lang/rust/pull/102028#issuecomment-1253440015 as it's solely mingw builds that are failing.
@oli-obk Any help with this would be much appreciated, as my understanding of developing on Windows is very limited, and last time I looked into this I wasn't able to figure out why it fails.
Is there anyone still fail to build libffi-sys on windows?You may need to install [mingw-w64-x86_64-autotools] to get it work.
I don't believe it's missing tooling, unless some other errors are hidden. The error we see is
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
@oli-obk Any help with this would be much appreciated, as my understanding of developing on Windows is very limited, and last time I looked into this I wasn't able to figure out why it fails.
yea, it's on the low priority list, but we definitely want to fix this
@ArchGuyWu Autotools is supposed to not be necessary since we bundle the necessary files, and we don't use it ourselves. It's possible the generated Makefile somehow still depends on something provided by it on MSYS2, in which case that should be resolved.
Autotools is a meta package,which just pulls in other packages,so we can try to figure out the Makefile exactly depends on which package.