Runtime failure on Windows on version 0.7.0.0 about zlib HOT 29 CLOSED

@fendor please give me a reproducer in a form of CI job.

from zlib.

@fendor I think ultimately it's either Cabal or GHC responsibility: if extra-libraries: z is not available or is no good to link with, they should tell so loudly instead of producing segfaulting artefacts.

from zlib.

@L0neGamer is it possible to reproduce the issue with other versions of GHC, newer than 9.2.8?

We have a CI job for Windows + GHC 9.2.8 which seems to succeed, so I'm at loss what's up.

from zlib.

Sorry I wasn't clear, when I said 9.2.8+ I meant that version and onwards. Also tested on .4.8 and .6.4

from zlib.

That's very weird. Can you contribute a reproducer expressed as a CI job?

from zlib.

Also, what's the Cabal version you are using?

from zlib.

cabal --version -> 3.10.2.1

I'm not sure how I'd do the CI job thing but I can try look into it? It'd probably be best for someone else to though.

from zlib.

Looking at the CI jobs, the only two relating to windows I can immediately see is one that builds and one that runs with bundled-c-zlib enabled, which is likely the issue here.

Can confirm that running cabal run -c 'zlib +bundled-c-zlib' results in the correct behaviour (that is, Test prints).

from zlib.

Well, but the job without bundled-c-zlib also succeeds in CI environment, right? If it runs tests, it means that it linked successfully.

from zlib.

True. I don't know enough how this stuff works or what the windows environment looks like; if you've reading material or a suggestion of where to read up I can have a go at some stage.

from zlib.

The thing is that zlib links fine on a Windows machine I have access to. So I cannot investigate any further without a portable reproducer.

It might be worth to raise the issue at https://gitlab.haskell.org/ghc/ghc/-/issues: it's GHC's responsibility to link correctly (or abort compilation if it's impossible to do so).

from zlib.

I'll look into raising it over there soon; at the very least maybe I'll be able to get a reproducer for here from them.

from zlib.

I was also bitten by this on my windows 10 machine. I was able to reproduce the issue while building cabal HEAD. GHC 9.4.8 and cabal 3.10.2.1.

from zlib.

No windows runner supported by github (it is just windows-2019 and windows-2022) seems to be able to reproduce the issue right now.

from zlib.

@fendor you can also try flipping pkg-config flag: I suspect GHA runners are likely to have it pre-installed, but your local environment probably does not.

Otherwise file a GHC issue please.

from zlib.

With the pkg-config flag:

$ cabal repl exes --constraint="zlib +pkg-config"                                                                                                                                                                                                                                                           Resolving dependencies...
Error: cabal-3.10.2.1.exe: Could not resolve dependencies:
[__0] trying: zlib-ghc-windows-0.1 (user goal)
[__1] trying: zlib-0.7.0.0 (dependency of zlib-ghc-windows)
[__2] trying: zlib:-bundled-c-zlib
[__3] rejecting: zlib:+pkg-config (conflict: pkg-config package zlib-any, not
found in the pkg-config database)
[__3] rejecting: zlib:-pkg-config (constraint from command line flag requires
opposite flag selection)
[__3] fail (backjumping, conflict set: zlib, zlib:bundled-c-zlib,
zlib:pkg-config)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: zlib, zlib-ghc-windows,
zlib:bundled-c-zlib, zlib:pkg-config
Try running with --minimize-conflict-set to improve the error message.    

I will file a ghc issue either way.

from zlib.

I agree. I am looking into it a little bit.

from zlib.

Tracking this issue in ghc: https://gitlab.haskell.org/ghc/ghc/-/issues/24531

from zlib.