Open tinyplasticgreyknight opened 8 years ago
The buildscript currently depends on make
and a C compiler (gcc
for windows-gnu
). Do you have both of these available?
I've got cygwin on that machine with both make
and gcc
, will it work if I run cargo
from a cygwin shell? Or will the cygwin environment confuse it further? I'll give it a try in the morning.
Also, is there a way to get better diagnostics on a failure?
Cygwin should work, or at least is worth a try; I use MSYS2 which is similar to cygwin in many ways and things work fine.
It would be possible to modify build.rs
to be a bit more specific about where the failure is. It would also be possible to remove the dependency on make
, but it's a bit trickier.
Cygwin gcc started spewing errors about undefined reference to __errno
, __getreent
, and what-have-you.
I installed MSYS2 with gcc 5.3.0 and GNU make 4.2.1. I get a similar panic to the above, but this time the error is After thoroughly cleaning out any leftover stuff in The directory name is invalid. (os error 267)
target
, I get the same spew about __errno
and so on.
I'll try playing with build.rs this evening and see if I can figure out what's breaking. (I won't have access to a Windows machine over the weekend though.)
I can build a fresh checkout of rust-lua53
just fine, incidentally; I'm only seeing these errors when trying to used it as a dependency of some other project.
Make sure you're running MSYS2 in the MINGW64 mode with mingw-w64-x86_64-gcc
and mingw-w64-x86_64-make
packages installed, not in the base MSYS2 mode with the bare gcc
and make
packages. Otherwise I expect things will not work as well. If you need it, I wrote a guide for a different Rust project, but it should still be mostly applicable (barring some out-of-date stuff).
I was using the ordinary packages, yes. Thanks for the guide, I'll try on Monday and see if it works.
@SpaceManiac tried installing MSYS2 as per your guide, and then compiling rust-lua53 It says the build failed in build.rs:176 but with some println! debugging I found that it doesen't print anything past line 151.
This is on a fresh x86_64 install of MSYS2 with the only package installed being mingw-w64-x86_64-toolchain
$ RUST_BACKTRACE=1 cargo build
Compiling lua v0.0.11 (file:///C:/Users/afonso/git/rust-lua53)
error: failed to run custom build command for `lua v0.0.11 (file:///C:/Users/afonso/git/rust-lua53)`
process didn't exit successfully: `C:\Users\afonso\git\rust-lua53\target\debug\build\lua-418791497191e787\build-script-build` (exit code: 101)
--- stdout
cargo:rustc-link-lib=static=lua
OPT_LEVEL = Some("0")
TARGET = Some("x86_64-pc-windows-gnu")
HOST = Some("x86_64-pc-windows-gnu")
TARGET = Some("x86_64-pc-windows-gnu")
TARGET = Some("x86_64-pc-windows-gnu")
HOST = Some("x86_64-pc-windows-gnu")
CC_x86_64-pc-windows-gnu = None
CC_x86_64_pc_windows_gnu = None
HOST_CC = None
CC = None
TARGET = Some("x86_64-pc-windows-gnu")
HOST = Some("x86_64-pc-windows-gnu")
CFLAGS_x86_64-pc-windows-gnu = None
CFLAGS_x86_64_pc_windows_gnu = None
HOST_CFLAGS = None
CFLAGS = None
PROFILE = Some("debug")
--- stderr
thread 'main' panicked at 'Error: The system cannot find the file specified. (os error 2)', build.rs:176
stack backtrace:
0: 0x48cd9a - std::sys::imp::backtrace::_write::h9de14d9391a68d69
1: 0x497437 - std::panicking::default_hook::{{closure}}::h35d735e0666e8a8c
2: 0x496ff3 - std::panicking::default_hook::h0e6a0c6e63807aa3
3: 0x4979be - std::panicking::rust_panic_with_hook::h6039b94a430bd351
4: 0x497866 - std::panicking::begin_panic::he7a6c483d1b92bfe
5: 0x497789 - std::panicking::begin_panic_fmt::h0eab1e13d28f1802
6: 0x4129dd - build_script_build::main::hcf949c5bd932e661
at C:\Users\afonso\git\rust-lua53/build.rs:176
7: 0x497648 - std::panicking::try::do_call::he7c18ae3ebb73a17
8: 0x4a1658 - _rust_maybe_catch_panic
9: 0x498163 - std::rt::lang_start::h27502d1630e59612
10: 0x412aaa - main
11: 0x4013b4 - _tmainCRTStartup
12: 0x4014e7 - mainCRTStartup
13: 0x7ffccd278363 - unit_addrs_search
@afonso360 I believe you are missing the make
package. If that's not enough, here's full steps on a clean system:
msys2-x86_64-20161025.exe
from websitepacman -Syu
to update corepacman -Syu
to update packagespacman -S git make mingw-w64-x86_64-gcc
wget https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-gnu/rustup-init.exe
./rustup-init --default-host x86_64-pc-windows-gnu --default-toolchain stable -y
export PATH=$USERPROFILE/.cargo/bin:$PATH
git clone https://github.com/jcmoyer/rust-lua53
cd rust-lua53
cargo test
@SpaceManiac Thanks it worked! Managed to compile it both as a crate and as a dependency to other projects, and with the latest commit I can compile it on MSVC
Is there any reason that gcc crate can't be used instead? It does all the heavy-lifting of finding msvc and works well for the msvc targets that are common on win32.
I've used it extensively on netcode.io and it works with with both win32 and linux.
I'm hitting the same error and not really looking to install a full cygwin toolchain to use this crate.
@SpaceManiac You shouldn't need to install Rust inside the MSYS environment. Rustup can install the x86_64-windows-pc-gnu target, and you just need to add the /bin/ folder for the MSYS environment to your PATH. Likewise, you could completely skip MSYS and just put MinGW onto your PATH.
In my experience, MSYS2 is the best way to install MinGW and keep it up to date, install C dependencies like libcurl, openssl, libsodium, and others that regularly come by when working with some Rust libraries, and to keep git up to date. This is why I recommend its use.
I'm not saying it's not a useful tool. It's just that you don't need to isolate your Rust installation from the rest of your PC's software ecosystem, making it much more fragile.
Running rustup-init
within MSYS2 doesn't actually install it into MSYS2. It still goes to %USERPROFILE%/.rustup
and is perfectly accessible from the rest of the system.
Does it? In that case, I retract my statement about it being fragile.
I ran into this problem while trying to reproduce issue #72 on Windows 7 64-bit.
I'm using the latest build:
I get the following error output: