Windows build suggestions

[FrankHB]

It seems that this project can be configured and built with a Visual Studio shell running a POSIX compatible shell:

• Enter the VS shell.
• Enter the compatible shell.
• Run ./configure -m=$M.
• Exit the compatible shell.
• Do the remained things of "Build step (Windows build machine)" in the BUILDING document.

Technically, they can be executed in the same host.

There are several distributions providing the compatible shell like bash. They should be considerable to ease the build process. They may also provide gcc, make and other POSIX-compliant tools, which makes the Microsoft toolchain (nmake, cl, link, etc) optional and results in kinds of smoother experience of migration between Windows and POSIX platforms.

I suggest two candidates to support:

• The bash environment provided by Windows 10 (currently still in preview).
• MSYS2. It is noticeable that with the package management mechanism, 3rdparty dependencies like libiconv (and even gcc for i686/x86-64 targets) can be installed automatically by the build script.

[burgerrg]

I updated the build procedure to use Cygwin. I suspect that MSYS2 may also work, but I haven't tried it.

I think the Windows 10 POSIX environment does not allow one to call native Windows executables, so it cannot be used with Microsoft Visual Studio. You could use gcc, but you'll have to port Chez Scheme to this new machine type, because the POSIX environment does not support the Windows API. I suspect that the POSIX environment is very close to Linux.

[ovenpasta]

I've succeded compiling with (Microsoft Visual C++ Build Tools 2015 + windows sdk 8.1) as explained by @FrankHB . I avoided installing the full visual studio but installed only the "Tools for Visual Studio" compiler tools - still 7gb of disk space) I used MSYS2 instead of cygwin without any problem. The only thing I had problems was maybe a bug in a Makefile /bin/sh: line 6: ../bin/scheme: No such file or directory Mf-base:275: recipe for target 'checkboot' failed

I've changed the line at s/Mf-Base:281 from | ../bin/scheme -b ../boot/$m/sbb -q to | ../bin/$m/scheme -b ../boot/$m/sbb -q then the compilation succeded. I don't know if this is correct though.

Would be nice to support also mingw64 as an option instead of Visual C++

[burgerrg]

@ovenpasta, thanks for pointing out the makefile's use of the symbolic link ../bin/scheme instead of the file ../bin/$m/scheme. I've fixed that.

With regard to using the mingw64 compiler, give it a try. I'd recommend looking at the c/Mf-a6le makefile and porting it to mingw64. Be sure to run the mats to check that the mingw run-time library handles all the floating-point library edge cases in the way Chez Scheme expects.

[matheusmoreira]

Hello! I'm trying to package Chez Scheme for msys2. Currently, I have a patch that adjusts configure so it recognizes MSYS_NT-* in uname's output.

The build fails with the following output:

==> Starting build()...
(cd ta6nt && make build)
(cd c ; make)
./make.bat
C:/dev/MSYS2-packages/chez-scheme-git/src/ChezScheme/ta6nt/c/make.bat: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
make[2]: *** [Makefile:28: ../bin/ta6nt/scheme] Error 127
make[1]: *** [Makefile:20: build] Error 2
make: *** [Makefile:19: build] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

I'm not sure where the problem is or where the ? came from. I read the makefiles mentioned in the log but was unable to figure it out.

@ovenpasta you were able to build using msys2; what could the above mean? Can you reproduce this behavior?

[ovenpasta]

Just very few steps... of course depends if you want 32 or 64 bit build, threaded or not, but just for example: execute Visual C++ 2015 x86 Native Build Tools Command Prompt from there run c:\msys64\msys2_shell.bat then cd to the ChezScheme source directory and run ./configure -m=i3nt them run make

[matheusmoreira]

I launched msys2 from the Native Build Tools Prompt and followed those exact steps but still got the same error:

$ cd ChezScheme
$ ./configure -m=i3nt
$ make
(cd i3nt && make build)
(cd c ; make)
./make.bat
C:/Users/Matheus/Downloads/dev/package/MSYS2-packages/chez-scheme-git/src/ChezScheme/i3nt/c/make.bat: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
make[2]: *** [Makefile:28: ../bin/i3nt/scheme] Error 127
make[1]: *** [Makefile:20: build] Error 2
make: *** [Makefile:19: build] Error 2

Your msys2 environment appears to be different. You have an msys2_shell.bat file; here it is called msys2_shell.cmd. Can you please post the output of uname -a on your system?

$ uname -a
MSYS_NT-6.3 Irlene-PC 2.5.1(0.297/5/3) 2016-05-16 10:51 x86_64 Msys

---

I noticed that Chez Scheme's Windows build target depends on nmake. This is probably the reason why msys2 had to be launched from the Visual Studio prompt.

On my system, the Native Build Tools Prompt adds the following directories to the PATH:

1. C:\Program Files (x86)\MSBuild\14.0\bin\amd64
2. C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64
3. C:\Program Files (x86)\Windows Kits\10\bin\x64
4. C:\Program Files (x86)\Windows Kits\10\bin\x86

The second entry is the directory which contains nmake and it is not present in my msys2's PATH, even when it is launched from the Build Tools Prompt:

$ nmake
bash: nmake: command not found

I found the cause of the shared library error when I tried to execute nmake via absolute path:

$ C:/'Program Files (x86)/Microsoft Visual Studio 14.0'/VC/BIN/amd64/nmake
C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/BIN/amd64/nmake.exe: error while loading shared libraries: api-ms-win-crt-math-l1-1-0.dll: cannot open shared object file: No such file or directory

So my Windows build system is probably defective for some reason.

Still, I wonder if it is possible to build Chez Scheme without relying on tools outside of msys2. Recent updates have rendered user configuration necessary to make msys2 inherit the full Windows PATH:

To void this, either launch start shell command using start_shell.cmd -use-full-path or inside Windows directly, set an environment variable for your user with name MSYS2_PATH_TYPE and value inherit.

This reflects the sentiment expressed in msys2's introduction:

When using the shells, try to remove as many entries from PATH as you can, ideally only leaving something like C:\Windows\system32. Mixing in programs from other MSYS2 installations, Cygwin installations or compiler toolchains is not supported and will probably break things in unexpected ways. Do not have these things in PATH when running MSYS2 unless you know exactly what you're doing.

Being able to simply execute pacman -S chez-scheme-git would make it really easy for Windows users to get the bleeding edge Chez Scheme implementation. However, that would mean building it as an msys2 package.

[matheusmoreira]

In my attempt to make Chez Scheme build as an msys2 package on my machine, I started developing patches that will create a new ta6msys2 machine type based on ta6nt.

I'm not sure if this is the best approach, but I got it to successfully compile several source files before failing with missing definition errors.

[ovenpasta]

Hi @matheusmoreira I've succeded building chez with mingw32. there is still some work to do but the basics are there. I've created some new targets, i3mw ti3mw a6mw ta6mw. By now I've finished only ti3mw. here is the branch https://github.com/ovenpasta/ChezScheme/tree/mingw

[matheusmoreira]

@ovenpasta I've set up a branch on my package repository for your version. The build still fails because it's trying to compile Chez Scheme as a Windows package. On msys2, it should build as a POSIX package.

==> Starting build()...
(cd ti3mw && make build)
(cd c ; make)
cp -p ../../c/statics.c statics.c
cp -p ../../c/system.h system.h
cp -p ../../c/types.h types.h
cp -p ../../c/version.h version.h
cp -p ../../c/externs.h externs.h
cp -p ../../c/globals.h globals.h
cp -p ../../c/segment.h segment.h
cp -p ../../c/thread.h thread.h
cp -p ../../c/sort.h sort.h
cp -p ../../c/segment.c segment.c
cp -p ../../c/alloc.c alloc.c
cp -p ../../c/symbol.c symbol.c
cp -p ../../c/intern.c intern.c
cp -p ../../c/gcwrapper.c gcwrapper.c
cp -p ../../c/gc-ocd.c gc-ocd.c
cp -p ../../c/gc.c gc.c
cp -p ../../c/gc-oce.c gc-oce.c
cp -p ../../c/number.c number.c
cp -p ../../c/schsig.c schsig.c
cp -p ../../c/io.c io.c
cp -p ../../c/new-io.c new-io.c
cp -p ../../c/print.c print.c
cp -p ../../c/fasl.c fasl.c
cp -p ../../c/stats.c stats.c
cp -p ../../c/foreign.c foreign.c
cp -p ../../c/prim.c prim.c
cp -p ../../c/prim5.c prim5.c
cp -p ../../c/flushcache.c flushcache.c
cp -p ../../c/schlib.c schlib.c
cp -p ../../c/thread.c thread.c
cp -p ../../c/expeditor.c expeditor.c
cp -p ../../c/scheme.c scheme.c
cp -p ../../c/itest.c itest.c
cp -p ../../c/windows.c windows.c
(cd ../zlib; CFLAGS=-m32 make -f win32/Makefile.gcc)
cp -p ../../c/main.c main.c
gcc -D_FORTIFY_SOURCE=2 -m32 -msse2 -Wpointer-arith -Wall -Wextra -O2 -D_REENTRANT -pthread -march=x86-64 -mtune=generic -O2 -pipe -c -DI386 -I../boot/ti3mw -I../zlib statics.c
gcc -D_FORTIFY_SOURCE=2 -m32 -msse2 -Wpointer-arith -Wall -Wextra -O2 -D_REENTRANT -pthread -march=x86-64 -mtune=generic -O2 -pipe -c -DI386 -I../boot/ti3mw -I../zlib segment.c
gcc -D_FORTIFY_SOURCE=2 -m32 -msse2 -Wpointer-arith -Wall -Wextra -O2 -D_REENTRANT -pthread -march=x86-64 -mtune=generic -O2 -pipe -c -DI386 -I../boot/ti3mw -I../zlib alloc.c
gcc -D_FORTIFY_SOURCE=2 -m32 -msse2 -Wpointer-arith -Wall -Wextra -O2 -D_REENTRANT -pthread -march=x86-64 -mtune=generic -O2 -pipe -c -DI386 -I../boot/ti3mw -I../zlib symbol.c
make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[3]: win32/Makefile.gcc: No such file or directory
make[3]: *** No rule to make target 'win32/Makefile.gcc'.  Stop.
make[2]: *** [Makefile:40: ../zlib/configure.log] Error 2
make[2]: *** Waiting for unfinished jobs....
In file included from system.h:43:0,
                 from alloc.c:17:
externs.h:44:38: fatal error: direct.h: No such file or directory
In file included from system.h:43:0,
                 from segment.c:35:
externs.h:44:38: fatal erro
```r: direct.h: No such file or directory
In file included from system.h:43:0,
                 from statics.c:18:
externs.h:44:38: fatal error: direct.h: No such file or directory
In file included from system.h:43:0,
                 from symbol.c:17:
externs.h:44:38: fatal error: direct.h: No such file or directory
compilation terminated.
compilation terminated.
compilation terminated.
compilation terminated.
make[2]: *** [Makefile:29: symbol.o] Error 1
make[2]: *** [Makefile:29: statics.o] Error 1
make[2]: *** [Makefile:29: segment.o] Error 1
make[2]: *** [Makefile:29: alloc.o] Error 1
make[1]: *** [Makefile:20: build] Error 2
make: *** [Makefile:19: build] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

[ovenpasta]

yes I know, you should use the mingw32 toolchain from msys2. I saw there are many msys2 packages compiled that way

[matheusmoreira]

@ovenpasta Success!

I created a mingw32 version of the package, as you suggested. I tested the build on the MINGW32 shell and it works. It even links against the system zlib instead of using the submodule. I'll tidy up the installation procedure later.

Are you planning on adding support for the other machine variants? You made more progress on that front than I did.

[ovenpasta]

Great ;) Actually the thing need some testing... I'll try to finish it this week. The actual variants will be i3mw a6mw ti3mw ta6mw. Anyone has ideas on the naming convention for the machine type? I used mw instead of nt. Does it sound good? :)

Il 04/07/2016 12:57, Matheus Moreira ha scritto:

@ovenpasta https://github.com/ovenpasta Success!

I created a |mingw32| version of the package https://github.com/matheusmoreira/MINGW-packages/commit/a758eed4f10815e9795871330b8cd3470e97199c, as you suggested. I tested the build on the MINGW32 shell and it works. It even links against the system |zlib| instead of using the submodule. I'll tidy up the installation procedure later.

Are you planning on adding support for the other machine variants? You made more progress on that front than I did.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cisco/ChezScheme/issues/19#issuecomment-230264421, or mute the thread https://github.com/notifications/unsubscribe/AI2neFNQGAVD1HZYRnzMYNTB6aWY3voWks5qSOczgaJpZM4IRiU5.

[matheusmoreira]

mw seems fine to me. I used msys2 for my POSIX build because I couldn't think of a good two letter abbreviation for it.

To track progress:

• [ ] i3mw
• [ ] a6mw
• [x] ti3mw
• [ ] ta6mw

[ovenpasta]

Hi... after 2 years, I've finally enabled also i3mw. Not that it took that much to do it.. ;) I've even did a small change (excluded getenv_s for the i3mw build) to be able to run chez scheme even in windows xp (only the unthreaded version). I could cross compile from linux and even run the mats with wine. There was a minor issue configuring zlib. At this point only the 64 bit version is missing, then I could create a pull request, are you interested in integrating this in master? You can see the code in this branch: https://github.com/ovenpasta/ChezScheme/tree/mingw

[burgerrg]

Commit e44a209f27f8670c23a1d402b3f968eaa10cad29 adds support for MinGW/MSYS builds of Chez Scheme on Windows. We still use the Microsoft C compiler. The Travis continuous integration server now uses a variant of MSYS_NT to build and test the Windows versions of Chez Scheme.

[jltaylor-us]

Is this issue resolved?

[mflatt]

I think we can probably close this. The v9.9.9 changed a lot about how Windows builds work, things generally work in a lot more Windows settings, and CI via GitHub Actions includes building Windows via GCC.

[mflatt]

Closing after the small further improvement of #764.