Scryer-prolog: 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.

[notoria]

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

[notoria]

@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

[notoria]

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.

[notoria]

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

[notoria]

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