Build fails on Windows: sh command not found during compilation (system cannot find the file specified)

[Yakumo-Yukari]

I'm trying to compile a Crystal program on Windows using:
crystal build src/app.cr
The build fails with:

In crystal\share\crystal\src\openssl\lib_crypto.cr:24:27

 24 | {% from_libressl = (`sh -c 'hash pkg-config 2> /dev/null || printf %s false'` != "false") &&
                          ^
Error: error executing command: sh -c 'hash pkg-config 2> /dev/null || printf %s false': The system cannot find the file specified.

The compiler is trying to execute a shell command (sh -c ...) during the OpenSSL detection phase, but sh is not available on native Windows. This suggests that the build process relies on Unix tools.

My question: Does Crystal support native development on Windows without requiring a Unix-like environment (like WSL, MSYS2, or Cygwin)? If so, how can I resolve this issue? I'm looking for a solution that works on Windows natively, not by running Crystal in a Linux-like environment.

I'm using:

Windows 11 (64-bit)

Crystal 1.19.1

Thanks.

[Blacksmoke16]

How did you install Crystal? And what is the output of crystal --version?

Based on the code:

crystal/src/openssl/lib_crypto.cr

Lines 9 to 24 in 9546b9f

	{% if flag?(:msvc) %}
	{% from_libressl = false %}
	{% ssl_version = nil %}
	{% for dir in Crystal::LIBRARY_PATH.split(Crystal::System::Process::HOST_PATH_DELIMITER) %}
	{% unless ssl_version %}
	{% config_path = "#{dir.id}\\openssl_VERSION" %}
	{% if config_version = read_file?(config_path) %}
	{% ssl_version = config_version.chomp %}
	{% end %}
	{% end %}
	{% end %}
	{% ssl_version ||= "0.0.0" %}
	{% else %}
	# these have to be wrapped in `sh -c` since for MinGW-w64 the compiler
	# passes the command string to `LibC.CreateProcessW`
	{% from_libressl = (`sh -c 'hash pkg-config 2> /dev/null || printf %s false'` != "false") &&

It seems to be falling back on sh since it seems you're not using MSVC, so it just assumes that sh is available.

[Yakumo-Yukari]

How did you install Crystal? And what is the output of ?crystal --version

Based on the code:

crystal/src/openssl/lib_crypto.cr

Lines 9 to 24 in 9546b9f

{% if flag?(:msvc) %}
{% from_libressl = false %}
{% ssl_version = nil %}
{% for dir in Crystal::LIBRARY_PATH.split(Crystal::System::Process::HOST_PATH_DELIMITER) %}
{% unless ssl_version %}
{% config_path = "#{dir.id}\openssl_VERSION" %}
{% if config_version = read_file?(config_path) %}
{% ssl_version = config_version.chomp %}
{% end %}
{% end %}
{% end %}
{% ssl_version ||= "0.0.0" %}
{% else %}

these have to be wrapped in sh -c since for MinGW-w64 the compiler

passes the command string to LibC.CreateProcessW

{% from_libressl = (sh -c 'hash pkg-config 2> /dev/null || printf %s false' != "false") &&
It seems to be falling back on since it seems you're not using MSVC, so it just assumes that is available.sh``sh

Yes, I started using the GNU portable version. After reinstalling the MSVC version, it could run, but I have to compile it in the x64 Native Tools. If I want to run it in PowerShell, I need to continue configuring. I have to say, this might turn some people away.

[ysbaddaden]

The gnu zip file isn't portable. It assumes a msys2 environment to run (or at least a bunch of unix tools to be available in PATH (sh, binutils, cc, ...).

See #16697

You can run Crystal in PowerShell but MSVC only provides vcvarsall.bat for cmd.exe to setup MSVC in a terminal, and there's no official PS1 equivalent (sigh).

I end up running cmd.exe to run vcvarsall.bat then run powershell.exe 🤷

[straight-shoota]

One vector of this issue is that the compiler assumes to use the same toolchain as it was built with. That might often be the case, but not necessarily so. A compiler built with MSVC is capable of producing an executable with the GNU toolchain and vice versa.

So perhaps the compiler could do some detection at runtime to figure out whether it's used in an MSVC environment or a GNU environment. We're already doing a similar thing to detect glibc vs musl on Linux.

This might not solve all toolchain issues on Windows, but at least it should implicitly choose a working toolchain.

[HertzDevil]

MSYS2 sets the MSYSTEM environment variable and a few others according to the current environment chosen (e.g. https://github.com/msys2/MSYS2-packages/blob/e3d5f24ca09a2ace5c305c7b4867236111b42b45/filesystem/msystem), it should be good enough for most purposes. Crystal's default triple would then change depending on whether this is set.

My main concern is if someone uses neither the MSVC developer prompt nor MSYS2, but then exposes both sets of binaries to %PATH%. GitHub CI's runner images are an example. What should Crystal do in this case?

[ysbaddaden]

Having a portable windows build that adapts to the current environment at runtime would be great 👍

@HertzDevil can we pick a default? or is it an issue because of issues with lib/dll to link?