jcmoyer / rust-lua53

Lua 5.3 bindings for Rust
MIT License
158 stars 45 forks source link

can't compile rust-lua on Windows #73

Open tinyplasticgreyknight opened 8 years ago

tinyplasticgreyknight commented 8 years ago

I ran into this problem while trying to reproduce issue #72 on Windows 7 64-bit.

I'm using the latest build:

rustc 1.12.1 (d4f39402a 2016-10-19)
cargo 0.13.0-nightly (109cb7c 2016-08-19)

I get the following error output:

   Compiling lua v0.0.9
error: failed to run custom build command for `lua v0.0.9`
process didn't exit successfully: `C:\Source\lua-embed-test\luahost\target\debug\build\lua-0442ce095437a50b\build-script-build` (exit code: 101)
--- stdout
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-pc-windows-gnu")
debug=true opt-level=0
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

--- stderr
thread 'main' panicked at 'Error: The system cannot find the file specified. (os error 2)', C:\Users\GK\.cargo\registry\src\github.com-1ecc6299db9ec823\lua-0.0.9\build.rs:145
SpaceManiac commented 8 years ago

The buildscript currently depends on make and a C compiler (gcc for windows-gnu). Do you have both of these available?

tinyplasticgreyknight commented 8 years ago

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?

SpaceManiac commented 8 years ago

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.

tinyplasticgreyknight commented 8 years ago

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 The directory name is invalid. (os error 267) After thoroughly cleaning out any leftover stuff in 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.

SpaceManiac commented 8 years ago

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).

tinyplasticgreyknight commented 8 years ago

I was using the ordinary packages, yes. Thanks for the guide, I'll try on Monday and see if it works.

afonso360 commented 7 years ago

@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
SpaceManiac commented 7 years ago

@afonso360 I believe you are missing the make package. If that's not enough, here's full steps on a clean system:

  1. Download and install msys2-x86_64-20161025.exe from website
  2. Open "MSYS2 MinGW 64-bit" shell
    1. pacman -Syu to update core
    2. When prompted, close the shell window
  3. Open "MSYS2 MinGW 64-bit" shell
    1. pacman -Syu to update packages
    2. pacman -S git make mingw-w64-x86_64-gcc
    3. wget https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-gnu/rustup-init.exe
    4. ./rustup-init --default-host x86_64-pc-windows-gnu --default-toolchain stable -y
    5. export PATH=$USERPROFILE/.cargo/bin:$PATH
    6. git clone https://github.com/jcmoyer/rust-lua53
    7. cd rust-lua53
    8. cargo test
afonso360 commented 7 years ago

@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

vvanders commented 7 years ago

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.

isavegas commented 7 years ago

@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.

SpaceManiac commented 7 years ago

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.

isavegas commented 7 years ago

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.

SpaceManiac commented 7 years ago

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.

isavegas commented 7 years ago

Does it? In that case, I retract my statement about it being fragile.