problem compiling on windows

[cduret]

Hello, I tried to compile scryer on windows 10 and I have a compilation error :

$ cargo build
   Compiling scryer-prolog v0.8.120 (C:\DEV\Covid-19\dev\prolog\scryer-prolog)
error[E0432]: unresolved import `nix::sys`
  --> src\main.rs:16:10
   |
16 | use nix::sys::signal;
   |          ^^^ could not find `sys` in `nix`

warning: unnecessary parentheses around block return value
   --> src\prolog\heap_print.rs:457:13
    |
457 |             (iter.next() == Some(']') && iter.next().is_none())
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses
    |
    = note: `#[warn(unused_parens)]` on by default

warning: unnecessary parentheses around block return value
   --> src\prolog\heap_print.rs:459:13
    |
459 |             (iter.next() == Some('}') && iter.next().is_none())
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `scryer-prolog`.

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

my OS windows 10 my rust version with mingw gcc backend

$ rustc --version
rustc 1.43.0 (4fb7144ed 2020-04-20)

cydu@pc-12571 MINGW64 /C/DEV/Covid-19/dev/prolog/scryer-prolog
$ gcc --version
gcc.exe (Rev2, Built by MSYS2 project) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[ghost]

What happens when you do this:

git clone https://github.com/nix-rust/nix
cd nix
cargo test

[cduret]

failed full trace here : https://pastebin.com/pLD9k50q Ok I have read nix-rust and saw its unix only

It means that scryer prolog does not support windows platform is that right ?

[mthom]

For now, yes, unfortunately. I think there's an issue in the nix github about Windows compatibility. I think that's the only thing in our way.

[cduret]

OK Will scryer will be windows compatible in the future ?

[mthom]

I certainly hope so! That depends on nix being more cooperative.

[cduret]

glad to hear that I'll stay tuned on that matter

[ghost]

@cduret , could you run this main.rs:

extern crate crossterm;
extern crate divrem;
#[macro_use]
extern crate downcast;
extern crate git_version;
extern crate indexmap;
#[macro_use]
extern crate lazy_static;
extern crate libc;
#[macro_use]
extern crate prolog_parser;
#[macro_use]
extern crate ref_thread_local;

mod prolog;

use crate::prolog::machine::*;
use crate::prolog::machine::streams::*;
use crate::prolog::read::*;

use std::sync::atomic::Ordering;

fn main() {
    let mut wam = Machine::new(readline::input_stream(), Stream::stdout());
    wam.run_top_level();
}

Comment/delete nix in Cargo.toml if necessary.

[cduret]

works great !

I got my scryer-prolog.exe (about 8M)

maybe if nix is just use for signal handling maybe could worth it to find one x-platform lib to do that

[ghost]

But if you do:

?- repeat, false.
Ctrl-c

You will lose everything (at least on *nix platform). Maybe a cfg could minimize this on Windows but there is work in progress on streams which could bring back the platform issue.

[ghost]

What is the output of rustup target list | grep installed?

[cduret]

yes its annoying especially for bad prolog programmers as me which often run in non termination loops.

I have compiled through msys2 terminal and use gnu backend

$ rustup target list | grep installed x86_64-pc-windows-gnu (installed)

[panasenco]

@cduret if you're still having issues running scryer-prolog on Windows, we just added a docker image that you can run through Docker Desktop. See instructions here.

[cduret]

thanks, hopefully it won't be required to use docker in the near future since I quite dislike the dockerized path that took software these days

[cduret]

I can now use scryer fairly well on windows with few minor tweaks patch

But event with Docker users the line feed problem is still an issue (#543)

The source files must all be in unix ending line format

[cduret]

I tried this morning to compile the last version of scryer on my windows workstation and it failed. This is related with the openSSL dependencies. I have installed last version of openssl in my mingw64 setup.

I have only one install of perl

$ which perl
/mingw64/bin/perl

cydu@pc-12571 MINGW64 /c/DEV/Covid-19/dev/prolog/scryer-prolog-master
$ perl -v

This is perl 5, version 28, subversion 0 (v5.28.0) built for MSWin32-x64-multi-thread

Copyright 1987-2018, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

error log is :

error: failed to run custom build command for `openssl-sys v0.9.58`

Caused by:
  process didn't exit successfully: `C:\DEV\Covid-19\dev\prolog\scryer-prolog-master\target\release\build\openssl-sys-c3e6717c6ec50a37\build-script-main` (exit code: 101)
--- stdout
cargo:rustc-cfg=const_fn
cargo:rerun-if-env-changed=X86_64_PC_WINDOWS_GNU_OPENSSL_NO_VENDOR
X86_64_PC_WINDOWS_GNU_OPENSSL_NO_VENDOR unset
cargo:rerun-if-env-changed=OPENSSL_NO_VENDOR
OPENSSL_NO_VENDOR unset
CC_x86_64-pc-windows-gnu = None
CC_x86_64_pc_windows_gnu = None
HOST_CC = None
CC = None
CFLAGS_x86_64-pc-windows-gnu = None
CFLAGS_x86_64_pc_windows_gnu = None
HOST_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
running "perl" "./Configure" "--prefix=/C/DEV/Covid-19/dev/prolog/scryer-prolog-master/target/release/build/openssl-sys-51e295b7018e87a6/out/openssl-build/install" "no-dso" "no-ssl3" "no-unit-test" "no-comp" "no-zlib" "no-zlib-dynamic" "no-engine" "no-async" "no-shared" "mingw64" "-O2" "-ffunction-sections" "-fdata-sections" "-m64" "-Wa,-mbig-obj"
Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw64
Using os-specific seed configuration

--- stderr

******************************************************************************
This perl implementation doesn't produce Unix like paths (with forward slash
directory separators).  Please use an implementation that matches your
building platform.

This Perl version: 5.28.0 for MSWin32-x64-multi-thread
******************************************************************************
thread 'main' panicked at '


Error configuring OpenSSL build:
    Command: "perl" "./Configure" "--prefix=/C/DEV/Covid-19/dev/prolog/scryer-prolog-master/target/release/build/openssl-sys-51e295b7018e87a6/out/openssl-build/install" "no-dso" "no-ssl3" "no-unit-test" "no-comp" "no-zlib" "no-zlib-dynamic" "no-engine" "no-async" "no-shared" "mingw64" "-O2" "-ffunction-sections" "-fdata-sections" "-m64" "-Wa,-mbig-obj"
    Exit status: exit code: 255


    ', C:\Users\cydu\.cargo\registry\src\github.com-1ecc6299db9ec823\openssl-src-111.9.0+1.1.1g\src\lib.rs:379:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

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

[ghost]

I sometimes use OPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0 OPENSSL_LIB_DIR=/usr/lib/openssl-1.0 cargo build --release to compile some projects that depends on openssl. If there is no way around this issue of perl then removing the commit that introduced openssl is the last solution to compile it.

[cduret]

compilation works now. appears that I used the wrong perl version.

$ pacman -R mingw-w64-x86_64-perl
$ pacman -S perl

did the trick ;-)

[triska]

The (direct) OpenSSL dependency is now also eliminated via #1600, on the rebis-dev branch.

Does compilation work on Windows now? If so, please consider closing this issue. Thank you a lot!

[mthom]

I tried to compile rebis-dev in Windows 10 using rustc 1.6.3, and no, it does not compile. gmp-mpfr-sys is the stumbling block.

[infogulch]

Some breadcrumbs:

From the gmp-mpfr-sys crate README.md#Building on Windows:

You can build on Windows with the Rust GNU toolchain and an up-to-date MSYS2 installation

Maybe that would work for some, but personally I'm not keen on managing GNU tooling via MSYS2 on Windows. Maybe cross compiling a windows target from a linux install and publishing scryer.exe in github releases would be easier?

Also note #18 support compilation to WASM which has an apparent solution to compile this crate to a wasm-wasi target which might be relevant to #615.

[triska]

I think cross-compiling would be great, and it would also be nice to provide executables directly!

However, I think it would be best to host any executables on a different site, separate from the source repository: This is because if (for example) Google falsely detects an executable on a site as a security risk, it may block access to the site or make Chrome display a security warning for it. I remember that this happened to another project once, and they had to contact Google and urge them to remove the warning. Therefore, I think executables are best host separately, so that the source repository always stays reliably accessible.

[aarroyoc]

If we want to have binaries available to download, maybe it's time to have a website!

As for Windows, it just keeps compiling on MSYS2, which gives native Windows binaries. I can try to cross-compile from Linux, which will be a nice addition for the CI

[triska]

https://github.com/mthom/scryer-prolog/issues/1619#issuecomment-1257586181 reports successful compilation ofrebis-dev on msys2-mingw64!

[triska]

The current master branch implements changes related to this issue, could you please try it?

[triska]

Does merged #1907 resolve this issue?

[rujialiu]

A lot of things have changed in recent months. Now I have no trouble building a native binary with a simple "Command Line Prompt" and Windows line ending issue has been solved, too. However, my Windows 10 has both msys2 and Visual Studio 2022 install (though I activated neither during the build process). It would be great if anyone can check if it works with a clean rust-only Windows.