cabal-install-3.6 fails to install network-3.1.2.2 in windows

[jneira]

• but cabal-install-3.4.0.0 is able to build it
• logs:

Configuring network-3.1.2.2...
configure: WARNING: unrecognized options: --with-compiler
checking build system type... x86_64-pc-msys
checking host system type... x86_64-pc-msys
checking for gcc... D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe accepts -g... yes
checking for D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe option to accept ISO C89... none needed
checking for an ANSI C-conforming const... yes
checking how to run the C preprocessor... D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe -E
checking for grep that handles long lines and -e... configure: error: no acceptable grep could be found in /d/ghcup/bin:/c/Users/atrey/AppData/Roaming/cabal/bin:/usr/bin:/mingw64/bin:/d/cabal/store/ghc-8.10.7/hsc2hs-0.68.7-640ce3a674b3ce528257d431f5e15fc40c5ab1a7/bin:/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0:/c/WINDOWS/System32/OpenSSH:/d/dev/app/git/cmd:/c/Users/atrey/AppData/Local/Microsoft/WindowsApps:/d/bin:/d/dev/ws/haskell/stack:/d/dev/app/emacs-26.2-x86_64/bin:/d/dev/app/Git/bin:/d/dev/app/curl_7_53_1_openssl_nghttp2_x64/bin:/d/dev/app/diffutils-2.8.7-1-bin/bin:/d/dev/app/grep-2.5.4-bin/bin:/d/dev/app/chocolatey/bin:/d/dev/app/vscode/bin:/d/Program Files/Java/jdk1.8.0_231/bin:/d/Program Files/7-Zip:/d/dev/app/node-v12.14.1-win-x64:/d/dev/ws/node.js:/d/dev/app/apache-maven-3.3.9/bin:/d/Program Files/PostgreSQL/11/bin:/d/bin/hls:/d/dev/app/python39/Scripts:/d/dev/app/python39:/d/ghcup/bin:/d/bin/cabal;/usr/xpg4/bin
cabal-3.6.0.0.exe: Failed to build network-3.1.2.2 (which is required by
exe:cabal from cabal-install-3.7.0.0). The failure occurred during the
configure step.

with cabal-3.4.0.0

Configuring network-3.1.2.2...
configure: WARNING: unrecognized options: --with-compiler
checking build system type... x86_64-pc-msys
checking host system type... x86_64-pc-msys
checking for gcc... D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe accepts -g... yes
checking for D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe option to accept ISO C89... none needed
checking for an ANSI C-conforming const... yes
checking how to run the C preprocessor... D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
....

Could it be related with #7510 (which i tested myself 🤦)?

[phadej]

...:/d/dev/app/python39:/d/ghcup/bin:/d/bin/cabal;/usr/xpg4/bin

are very much : separated indeed.

[Mikolaj]

Is this solved, then? If not, how exactly do I reproduce? I don't see any direct instruction for that.

Edit: never mind, I'm on Linux and this is probably Windows.

[jneira]

I tested it in a misys2 bash console and same error with cabal --store-dir /d/cabal/store2 install network --lib

[Mikolaj]

@jneira: you are probably using master branch? How about 3.6? Any idea where are the : separators @phadej mentions coming from? Any idea why it worked previously, when people tested the PR?

[jneira]

@jneira: you are probably using master branch? How about 3.6?

I think I am using 3.6 official release but I will confirm

Any idea where are the : separators @phadej mentions coming from?

the problem maybe is the unique ; in the list and no :? not sure

Any idea why it worked previously, when people tested the PR?

not yet ☺️ but maybe it is not related, will try again the pr commit to discard

[Mikolaj]

@jneira: you are probably using master branch? How about 3.6?

I think I am using 3.6 official release but I will confirm

I've seen cabal-install-3.7.0.0 in your log above, hence asking.

the problem maybe is the unique ; in the list and no :? not sure

Huh, I'm not sure any more.

[Edited: removed all the rest of my musings, because they didn't make sense. Read #7494 instead.]

[Edit2: after reading #7494, I agree there should be no colons, but only semicolons in PATH. So cabal is giving wrong PATH to configure or the following not always holds: "When cabal is called the msys2-runtime converts the environment block to contain windows paths since Cabal is a Windows program and expect a Windows style environmental block."]

[Edit3: perhaps it depends on whether cabal is called from Windows console or msys/cygwin terminal or whether the cabal binary is more or less native Windows binary (if that's possible)?]

[jneira]

3.7 is shown cause I was trying to build a recent commit of cabal but using an older version of cabal itself

[Mikolaj]

3.7 is shown cause I was trying to build a recent commit of cabal but using an older version of cabal itself

Oh, right, my bad.

[Mikolaj]

@Mistuke: does the log tell you anything? What can be going wrong?

[phadej]

My guess is that we don't overwrite PATH provided by bash console itself.

And if you test in PowerShell the problem doesn't arise. Can @jneira try to build in PowerShell?

[jneira]

I am afraid the log from the description was from a powershell session 😕
I tested it in a msys bash and same result

[jneira]

Ok, i am afraid there had been some confusion that I could have avoided posting the full logs with versions of tooling:

PS D:\dev\ws\haskell\issues> cabal --version
cabal-install version 3.6.0.0
compiled using version 3.6.1.0 of the Cabal library
PS D:\dev\ws\haskell\issues> $(gcm cabal).path
D:\ghcup\bin\cabal.exe
PS D:\dev\ws\haskell\issues> cabal --store-dir D:\cabal\store2 install network --lib
Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
 - hsc2hs-0.68.7 (exe:hsc2hs) (requires build)
 - network-3.1.2.2 (lib:network) (requires build)
Starting     hsc2hs-0.68.7 (exe:hsc2hs)
Building     hsc2hs-0.68.7 (exe:hsc2hs)
Installing   hsc2hs-0.68.7 (exe:hsc2hs)
Completed    hsc2hs-0.68.7 (exe:hsc2hs)
Starting     network-3.1.2.2 (all, legacy fallback)

Failed to build network-3.1.2.2. The failure occurred during the configure
step.
Build log (
D:\cabal\logs\ghc-8.10.7\network-3.1.2.2-43da37077e8a7b3eeb1dbd1af4e0673f5a10eb39.log
):
Configuring network-3.1.2.2...
configure: WARNING: unrecognized options: --with-compiler
checking build system type... x86_64-pc-msys
checking host system type... x86_64-pc-msys
checking for gcc... D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe accepts -g... yes
checking for D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe option to accept ISO C89... none needed
checking for an ANSI C-conforming const... yes
checking how to run the C preprocessor... D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe -E
checking for grep that handles long lines and -e... configure: error: no acceptable grep could be found in /d/ghcup/bin:/c/Users/atrey/AppData/Roaming/cabal/bin:/usr/bin:/mingw64/bin:/d/cabal/store2/ghc-8.10.7/hsc2hs-0.68.7-640ce3a674b3ce528257d431f5e15fc40c5ab1a7/bin:/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0:/c/WINDOWS/System32/OpenSSH:/d/dev/app/git/cmd:/c/Users/atrey/AppData/Local/Microsoft/WindowsApps:/d/bin:/d/dev/ws/haskell/stack:/d/dev/app/emacs-26.2-x86_64/bin:/d/dev/app/Git/bin:/d/dev/app/curl_7_53_1_openssl_nghttp2_x64/bin:/d/dev/app/diffutils-2.8.7-1-bin/bin:/d/dev/app/grep-2.5.4-bin/bin:/d/dev/app/chocolatey/bin:/d/dev/app/vscode/bin:/d/Program Files/Java/jdk1.8.0_231/bin:/d/Program Files/7-Zip:/d/dev/app/node-v12.14.1-win-x64:/d/dev/ws/node.js:/d/dev/app/apache-maven-3.3.9/bin:/d/Program Files/PostgreSQL/11/bin:/d/bin/hls:/d/dev/app/python39/Scripts:/d/dev/app/python39:/d/ghcup/bin:/d/bin/cabal;/usr/xpg4/bin
cabal-3.6.0.0.exe: Failed to build network-3.1.2.2. See the build log above
for details.

with -v3 we can see the configure invocation:

"D:\ghcup\msys64\usr\bin\sh.exe" "C:\/TEMP/cabal-install.-6000/dist-newstyle/tmp/src-6000/network-3.1.2.2/configure" "--with-compiler=ghc" "--prefix=D:\cabal\store2\ghc-8.10.7\network-3.1.2.2-43da37077e8a7b3eeb1dbd1af4e0673f5a10eb39" "--bindir=D:\cabal\store2\ghc-8.10.7\network-3.1.2.2-43da37077e8a7b3eeb1dbd1af4e0673f5a10eb39\bin" "--libdir=D:\cabal\store2\ghc-8.10.7\network-3.1.2.2-43da37077e8a7b3eeb1dbd1af4e0673f5a10eb39\lib" "--libexecdir=D:\cabal\store2\ghc-8.10.7\network-3.1.2.2-43da37077e8a7b3eeb1dbd1af4e0673f5a10eb39\libexec" "--datadir=D:\cabal\store2\ghc-8.10.7\network-3.1.2.2-43da37077e8a7b3eeb1dbd1af4e0673f5a10eb39\share" "--sysconfdir=D:\cabal\store2\ghc-8.10.7\network-3.1.2.2-43da37077e8a7b3eeb1dbd1af4e0673f5a10eb39\etc" "CC=D:\ghcup\ghc\8.10.7\lib\../mingw/bin\gcc.exe"

[Mistuke]

[Edit2: after reading #7494, I agree there should be no colons, but only semicolons in PATH. Co cabal is giving wrong PATH to configure or the following not always holds: "When cabal is called the msys2-runtime converts the environment block to contain windows paths since Cabal is a Windows program and expect a Windows style environmental block."]

It does, but the problem is that the PATH environment variable is special. At startup sh will convert whatever PATH it inherits.. since the shell itself uses :.

So Cabal has Windows Path -> sh (converts everything)

It looks like we have two seemingly incompatible requirements. 2.70 requires different handling for ACLOCAL_PATH but PATH looks except from translations..

The problem seems to be that the packaged network comes with an configure script generated from the old version of autoconf while (at least me) tested with network github which requires you to run autoreconf to generate a new configure.

It looks like @phadej was right, we need a more complicated fix due to packaged configure scripts.

There are likely 3 options:

1. lobby for an upstream fix (unlikely)
2. lobby for msys2 to revert https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=35a1c64600894ecc3b06b6c4b273952db7c8fc83 down stream.
3. Make cabal send unix paths instead of Windows paths to all PATHs it sends to configure (including the path to configure scripts themselves).

But the last time I tried 3 the error became even more cryptic

configure: error: cannot find required auxiliary files 

with an empty files list. Can be worth trying again though. I am also worried that paths exported end up in configure output.

So we can try just modifying the path to configure scripts to unix paths and see if that works if not I think 2 is likely the only option left.

[Mikolaj]

@Mistuke: thank you for the hints. So it fails for you too, consistently, when network is being installed from Hackage, as opposed to from github?

@emilypi, @gbaz, @fgaz: we have a situation. My PR bombed out and cabal 3.6.1 is a dud on Windows. I think we should announce the workaround is to install network (and possibly others) from github instead of Hackage.

Perhaps a workaround until we can create and release 3.6.2 is to beg Kazu to release network with a new version of the configure script? Oh no, it won't help, because hpack uses Configure and a few others: https://hackage-search.serokell.io/?q=build-type%3A.*Configure

@Mistuke: how to approach 3? By chance, do you have any patches lying around?

Edit: BTW, am I right that a Windows bootstrap test would catch that? Build master, wipe store, build master again using the just obtained cabal exe? It would be great to extend our Windows (and other) CI with this.

[Mistuke]

@Mistuke: thank you for the hints. So it fails for you too, consistently, when network is being installed from Hackage, as opposed to from github?

Yes, But this I think is a second order effect. Another change in autoconf 2.70 is that the standard macros don't look for nearly as many programs as they did before.

So in 2.70 there's no search for programs such as grep etc. https://github.com/haskell/network/runs/3186900662#step:10:23

@Mistuke: how to approach 3? By chance, do you have any patches lying around?

Unfortunately it looks like filepath has no facilities to convert Windows to POSIX paths, so it has to be done manually.
I can send a PR on Saturday, it's not hard to do manually but during the week I don't have time usually.

Edit: BTW, am I right that a Windows bootstrap test would catch that? Build master, wipe store, build master again using the just obtained cabal exe? It would be great to extend our Windows (and other) CI with this.

Cabal isn't a configure based package is it? so it wouldn't catch it. Though a simple test can be made which uses configure, and searches for a standard program like find or grep.

[Mistuke]

It looks like converting the top level path is enough:

Cabal currently does

"C:\tools\msys64\usr\bin\sh.exe" "C:\/Users/xbox/source/repos/network/configure" "--with-compiler=ghc" "--prefix=C:\Users\xbox\AppData\Roaming\cabal" "--bindir=C:\Users\xbox\AppData\Roaming\cabal\bin" ...

but if it does

"C:\tools\msys64\usr\bin\sh.exe" "/c/Users/xbox/source/repos/network/configure" "--with-compiler=ghc" "--prefix=C:\Users\xbox\AppData\Roaming\cabal" "--bindir=C:\Users\xbox\AppData\Roaming\cabal\bin" ...

Configure seems to throw a

/c/Users/xbox/source/repos/network/configure: line 2615: :=;: command not found

message but that's not fatal and everything seems to work right. But we need a more extensive way of testing this time...

But it looks like most of those configure packages don't work on Windows?

[Mikolaj]

But it looks like most of those configure packages don't work on Windows?

Those listed by the serokell.io invocation above that @phadej constructed? I'd guess at least hpack, time and a few others work on Windows.

Cabal isn't a configure based package is it? so it wouldn't catch it. Though a simple test can be made which uses configure, and searches for a standard program like find or grep.

But it depends on network, so that would be caught, right? And possibly other problems. For a good measure, we could force a rebuild of packages that GHC provides, like time, to be sure.

[Mistuke]

But it depends on network, so that would be caught, right? And possibly other problems. For a good measure, we could force a rebuild of packages that GHC provides, like time, to be sure.

Ah, hmm. It would work, but be very slow. I wouldn't do it on every build. For normal builds I'd just have a collection of configue scripts generated by different autoconf versions. You don't actually need to build the packages, just pass cabal configure.

[Mistuke]

The problem is, how do you test changing behavior of the macros and files like config.guess etc that aren't part of the package always but can be provided by autoconf. You need to be able to test different autoconf versions I think..

[Mikolaj]

The problem is, how do you test changing behavior of the macros and files like config.guess etc that aren't part of the package always but can be provided by autoconf. You need to be able to test different autoconf versions I think..

Good point.

[gbaz]

@jneira do you think you could put together a PR adding tests for just running the configure scripts for network generated from both older and newer autoconf versions? I.e. the successful and failing ones for network, for starters? :-)

[jneira]

@jneira do you think you could put together a PR adding tests for just running the configure scripts for network generated from both older and newer autoconf versions? I.e. the successful and failing ones for network, for starters? :-)

I dont know the cabal test suite in deep but i could try it.

Sorry for not testing all cases, i should have tested the pr version against the conf files included in the hackage version of network.

In all my tests i did a cabal get network && cd network, removed the conf files and regenerated them with autoreconf -i, doing a final cabal build.

It worked with the new cabal using conf files generated with autoconf 2.69 in my machine. But i did not test the new cabal against the existing conf files generated in linux and included in the package 🤦. I think i will do that test with the pr version, just in case.

@Mistuke does that test fits the actual diagnostic of the bug?

(@gbaz has suggested that maybe the autoreconf version used to generate the conf files for the distributed package is different from 2.69, to investigate, finding out what autoreconf version is being used in the linux machine used to upload the package network to hackage)

[jneira]

i am afraid all packages with configure step are affected, i've tried time and process and both fail with the same error :-(

[hsyl20]

configure: error: cannot find required auxiliary files

I have debugged the same issue a few months ago in the GHC build. The relevant ticket/comment is https://gitlab.haskell.org/ghc/ghc/-/issues/19189#note_332168

It led me to remove the use of config.sub/config.guess in base and ghc-bignum (https://gitlab.haskell.org/ghc/ghc/-/commit/bcaa36c4277dc577863132da2f95645715e2a15e). Sadly this fix can't be easily generalized to other packages...

I have opened this issue upstream at the time (https://savannah.gnu.org/support/?110448) which got the following responses by email:

But $PATH_SEPARATOR=":"

Intuitively, I would expect PATH_SEPARATOR to be ";" on Windows (unless you're using CygWin).

Indeed. And if you are using Cygwin, shouldn't you be using /cygdrive/c/... instead of c:... ? (or however it's spelled, it's been a very long time since I used Cygwin)

Edit: I had missed that @Mistuke explained all this in #7494

[madjestic]

Hey guys,
I just wanted to report that I am getting a similar issue:

PS C:\Users\madje\Projects\Haskell\RedViz> cabal build
Warning: C:\cabal\config: Tabs used as indentation at 62:7, 63:7, 64:7, 65:7,
66:7, 71:3, 74:4, 75:4, 76:4
Resolving dependencies...
Build profile: -w ghc-9.2.8 -O1
In order, the following will be built (use -v for more details):
 - hspec-expectations-0.8.4 (lib) (requires build)
 - network-3.1.4.0 (lib:network) (requires build)
 - profunctors-5.6.2 (lib) (requires build)
 - quickcheck-io-0.2.0 (lib) (requires build)
 - semigroupoids-6.0.0.1 (lib) (requires build)
 - smallcheck-1.2.1.1 (lib) (requires build)
 - text-iso8601-0.1 (lib) (requires build)
 - th-expand-syns-0.4.11.0 (lib) (requires build)
 - th-lift-instances-0.1.20 (lib) (requires build)
 - invariant-0.6.2 (lib) (requires build)
 - hspec-core-2.11.5 (lib) (requires build)
 - semialign-1.3 (lib) (requires build)
 - free-5.2 (lib) (requires build)
 - th-reify-many-0.1.10 (lib) (requires build)
 - hspec-smallcheck-0.5.3 (lib) (requires build)
 - hspec-2.11.5 (lib) (requires build)
 - aeson-2.2.1.0 (lib) (requires build)
 - adjunctions-4.4.2 (lib) (requires build)
 - th-orphans-0.13.14 (lib) (requires build)
 - aeson-pretty-0.8.10 (lib) (requires build)
 - kan-extensions-5.2.5 (lib) (requires build)
 - th-utilities-0.2.5.0 (lib) (requires build)
 - lens-5.2.3 (lib) (requires build)
 - store-0.7.18 (lib) (requires build)
 - linear-1.22 (lib) (requires build)
 - sdl2-2.5.5.0 (lib) (requires build)
 - RedViz-0.3.0.0 (lib) (first run)
Starting     quickcheck-io-0.2.0 (lib)
Starting     hspec-expectations-0.8.4 (lib)
Starting     text-iso8601-0.1 (lib)
Starting     smallcheck-1.2.1.1 (lib)
Starting     th-lift-instances-0.1.20 (lib)
Starting     th-expand-syns-0.4.11.0 (lib)
Starting     semigroupoids-6.0.0.1 (lib)
Starting     profunctors-5.6.2 (lib)
Starting     network-3.1.4.0 (all, legacy fallback)
Building     hspec-expectations-0.8.4 (lib)
Building     smallcheck-1.2.1.1 (lib)
Building     quickcheck-io-0.2.0 (lib)
Building     text-iso8601-0.1 (lib)
Building     th-lift-instances-0.1.20 (lib)
Building     th-expand-syns-0.4.11.0 (lib)
Building     semigroupoids-6.0.0.1 (lib)
Building     profunctors-5.6.2 (lib)
Installing   quickcheck-io-0.2.0 (lib)
Installing   th-lift-instances-0.1.20 (lib)
Installing   hspec-expectations-0.8.4 (lib)
Installing   th-expand-syns-0.4.11.0 (lib)
Completed    quickcheck-io-0.2.0 (lib)
Completed    th-lift-instances-0.1.20 (lib)
Installing   text-iso8601-0.1 (lib)
Completed    hspec-expectations-0.8.4 (lib)
Installing   smallcheck-1.2.1.1 (lib)
Completed    th-expand-syns-0.4.11.0 (lib)
Completed    text-iso8601-0.1 (lib)
Completed    smallcheck-1.2.1.1 (lib)
Installing   profunctors-5.6.2 (lib)
Completed    profunctors-5.6.2 (lib)
Installing   semigroupoids-6.0.0.1 (lib)
Completed    semigroupoids-6.0.0.1 (lib)

Failed to build network-3.1.4.0. The failure occurred during the configure
step.
Build log (
C:\cabal\logs\ghc-9.2.8\network-3.1.4.0-120f999809acd05b40d1a657a2212af8047f0204.log
):
Configuring network-3.1.4.0...
cabal-3.6.0.0.exe: The package has a './configure' script. If you are on
Windows, This requires a Unix compatibility toolchain such as MinGW+MSYS or
Cygwin. If you are not on Windows, ensure that an 'sh' command is discoverable
in your path.

cabal-3.6.0.0.exe: Failed to build network-3.1.4.0 (which is required by
RedViz-0.3.0.0). See the build log above for details.

I am on Windows 11 all installed with defaults.

> ghc -V
The Glorious Glasgow Haskell Compilation System, version 9.2.8

> cabal -V
cabal-install version 3.6.0.0
compiled using version 3.6.1.0 of the Cabal library

I am using powershell.

Thanks!

[gbaz]

"I am on Windows 11 all installed with defaults." -- what does this mean? how did you install cabal? with ghcup? did you install the necessary mingw/msys tooling along with it? how did you install that?

[ulysses4ever]

@madjestic 3.6 is a rather old release. Could you try the latest one? (E.g. ghcup install cabal latest and then set it as the default).

[madjestic]

"I am on Windows 11 all installed with defaults." -- what does this mean? how did you install cabal? with ghcup? did you install the necessary mingw/msys tooling along with it? how did you install that?

ghcup, all defaults as recommended, msys2, stack, hls.

[madjestic]

@madjestic 3.6 is a rather old release. Could you try the latest one? (E.g. ghcup install cabal latest and then set it as the default).

I will try that, thanks!

[madjestic]

Hey guys,

I've tried ghc 9.4.7 and cabal 3.10.1.0, the error message is the same.

[Mikolaj]

Thanks for the experiment. Does compiling C programs that use ./configure work? Actually, does running sh work?

[madjestic]

I will explain how I am doing that: I've got ghcup installed as recommended on the website, ugraded and updated. I start the Powershell, navigate to the haskell project (a clean test project with network added into the project's cabal as the only dependency besides base), run cabal build and get this error.

I am not aware of how I am supposed to use sh on ./configure under windows. Running these commands in Powershell just gives errors. Where can I read about the necessary steps involving sh and configure, @Mikolaj ?

Regards,
Vlad

[Mikolaj]

@madjestic: actually, I'm quite clueless regarding Windows --- I was just following your error message. I'm also trying to understand how broken your toolchain is and what may be responsible for that.

@hasufell: is ghcup so plug-and-play on Windows, e.g., does it install msys2 so that the user can run sh in powershell or install a C library from source [edit: with ./configure] (is there a good smoke test library to use in that role?)?

[madjestic]

I can only humbly suggest that my toolchain is probably as vanilla as most windows 11 users will experience. I kept it very simple and nearly everything is a default, I was not trying being clever or customize my environment beyond adding SDL2 dll to the path and cabal/config.

[Mikolaj]

I can only humbly suggest that my toolchain is probably as vanilla as most windows 11 users will experience.

That's what I'm worried about. :D

[Bodigrim]

My experience is that building network on Windows requires MinGW / MSYS terminal. Usually Git Bash works well. It's a pity if this is not documented clearly, but probably more an issue for network than for Cabal.

[hasufell]

is ghcup so plug-and-play on Windows, e.g., does it install msys2 so that the user can run sh in powershell

Yes, we:

• install msys2
• add the msys2 bin directories to cabals extra-prog-path

That means you don't need an msys2 shell, because cabal knows about those directories.

If the cabal config doesn't include this, it will fail.

[Mikolaj]

@madjestic: can you reconcile these bits of info? Are msys2 paths in your cabal config?

[madjestic]

I will take a look and let you know asap, thanks!

[madjestic]

Hey guys,
I think that I do have msys2 paths in the cabal config. Here's my cabal/config.

Am I missing something there?

[gbaz]

those paths look correct. perhaps you can download and build network individually, running cabal at a high verbosity, so that we could see the error logs, which may be more informative?

[jasagredo]

I think this is a manifestation of this other issue I created #9519

[gbaz]

Not so sure. If it was the exec handling and git handling, not sure how that might have affected build?

[jasagredo]

Indeed. My comment was before I started investigating deeply the fix for my ticket. This is NOT related to #9519.