Cannot build on Windows with GHC 9.4

[Bodigrim]

As witnessed by CI at https://github.com/Bodigrim/libarchive/actions/runs/6605253232/job/17940229969#step:14:124:

Configuring libarchive-3.0.4.2...
Preprocessing library for libarchive-3.0.4.2..
c2hs.exe: C header contains errors:

Error: p/ghc/9.4.7/mingw/lib/clang/14.0.6/include/ia32intrin.h:222: (column 29) [ERROR]  >>> Syntax error !
  The symbol `unsigned' does not fit here.

Error: Process completed with exit code 1.

This is presumably because starting from 9.4 GHC uses clang instead of gcc on Windows, thus different headers, which c2hs is incapable to deal with.

One might hit this issue by building ghcup on Windows with GHC 9.4. CC @hasufell.

I assume that this actually a general issue with c2hs. CC @deech.

[hasufell]

I think there's a bug in CI that always installs and uses 9.4.7

[hasufell]

I tried to compile ghcup with 9.4.7 and my impression so far is that it's completely busted.

I'm getting things like

@bgamari

[hasufell]

@bgamari I don't really have the capacity to go through GHC issue tracker. Is this tracked anywhere? 9.4 is effectively broken on windows. Are GHC devs aware?

[chreekat]

The switch to clang did cause a few bug reports to get opened for 9.4. Most have been fixed already. But I don't think this one has been brought to GHC's attention. It might be good if someone could open a ticket.

[wz1000]

@hasufell I can't reproduce your failure, do you have a reproducer? Is cabal generating the macros?

I can reproduce the original failure, which seems to be a bug in c2hs. Here is the bit of the header file it chokes on:

static __inline__ unsigned long long __DEFAULT_FN_ATTRS_CAST
_castf64_u64(double __A) {
  return __builtin_bit_cast(unsigned long long, __A);
}

[hasufell]

I can't reproduce your failure, do you have a reproducer? Is cabal generating the macros?

I can't at the moment either. I reinstalled ghcup on windows, which performed a new and updated msys2 installation. Maybe some older msys2 fails with newer GHC?

[wz1000]

Maybe some older msys2 fails with newer GHC?

That seems plausible. ghcup should not be using the same toolchain across different GHC versions.

[hasufell]

Maybe some older msys2 fails with newer GHC?

That seems plausible. ghcup should not be using the same toolchain across different GHC versions.

What?

[wz1000]

It is incorrect to set up one single toolchain to be shared by multiple different versions of GHC, as GHCup currently does.

[hasufell]

It is incorrect to set up one single toolchain to be shared by multiple different versions of GHC, as GHCup currently does.

I'm not sure what you mean with that really or how you envision to manage msys2. Please be more specific.

Are you saying that every specific GHC version only works with a specific range of msys2 versions? If so, it's the obligation of GHC devs to provide a table for this compatibility.

Otherwise, I'm not sure what you mean.

[wz1000]

Are you saying that every specific GHC version only works with a specific range of msys2 versions? If so, it's the obligation of GHC devs to provide a table for this compatibility.

Every windows GHC bindist ships with a toolchain it is guaranteed to work for. GHCup should be using the toolchain that the particular GHC version shipped with.

This is probably not the right place for this discussion.

[hasufell]

Every windows GHC bindist ships with a toolchain it is guaranteed to work for. GHCup should be using the toolchain that the particular GHC version shipped with.

Yeah, I think you're misunderstanding how things work on windows. We're not overwriting the GHC shipped toolchain.

Msys2 is installed by chocolatey and stack and ghcup exactly once to install system packages, support autoconf based setups etc.

[bgamari]

@bgamari I don't really have the capacity to go through GHC issue tracker. Is this tracked anywhere? 9.4 is effectively broken on windows. Are GHC devs aware?

If I understand correctly, this isn't a GHC bug. It looks to me like is another case of the root cause of haskell/c2hs#268. Specifically language-c, which is depended upon by c2hs, can't parse some dialects of C.

[hasufell]

If I understand correctly, this isn't a GHC bug.

I don't know much about c2hs, but why does it not surface with older GHCs then?

[bgamari]

I don't know much about c2hs, but why does it not surface with older GHCs then?

Presumably because the headers provided with older GHC toolchains don't rely on syntax outside of the dialect understood by c2hs.

[hasufell]

I don't know much about c2hs, but why does it not surface with older GHCs then?

Presumably because the headers provided with older GHC toolchains don't rely on syntax outside of the dialect understood by c2hs.

I see. So I guess c2hs could blame GHC for using an unsupported dialect and GHC can blame c2hs for being an incomplete C parser ;)

This is an unfortunate coupling.

[deech]

Can we try this as a stop gap? haskell/c2hs#291 (comment)

[bgamari]

Yes, the whole situation is generally unfortunate. haskell/c2hs#291 (comment) does seem like a plausible workaround. A better approach would arguably be to add support for __builtin_bit_cast to language_c.

Ultimately, I think it would be even better if c2hs stopped depending upon language-c; IMHO trying to parse a language as complex as C in a general purpose tool like c2hs is an up-hill battle. Sadly, this would essentially amount to a rewrite.

[hasufell]

@bgamari I used to use ghcup as a test case for whether a GHC is recommendable: can I build ghcup with that GHC on all platforms? If I can't (even if it's a libraries fault), I'd tilt towards "no".

I'm not sure what GHC itself can do about that situation.

[deech]

@bgamari While your point is well taken in this case __builtin_bit_cast per gcc is a C++ only construct. I don't understand why it would be present in C headers.

[bgamari]

@bgamari While your point is well taken in this case __builtin_bit_cast per gcc is a C++ only construct. I don't understand why it would be present in C headers.

The C standard specifies that identifiers starting with double-underscores are reserved for definition by the implementation. While gcc specifies that __builtin_bit_cast is C++-only, clang will happily accept it in C sources (and, as we see here, the compiler-rt headers used by clang take advantage of this fact).

[bgamari]

I can confirm that this package builds with a c2hs built against visq/language-c#96.

[Bodigrim]

With language-c-0.9.3 the original error is gone, but another one appears:

ld.lld: error: undefined symbol: zzlibzm0zi6zi3zi0zm984d56bc097043d23751b719ae16f2523b51dc2e_CodecziCompressionziZZlibziStream_GZZip_closure
>>> referenced by libHSzlib-0.6.3.0-984d56bc097043d23751b719ae16f2523b51dc2e.a(GZip.o):(.text)
>>> referenced by libHSzlib-0.6.3.0-984d56bc097043d23751b719ae16f2523b51dc2e.a(GZip.o):(zzlibzm0zi6zi3zi0zm984d56bc097043d23751b719ae16f2523b51dc2e_CodecziCompressionziGZZip_decompress1_info)
>>> referenced by libHSzlib-0.6.3.0-984d56bc097043d23751b719ae16f2523b51dc2e.a(GZip.o):(zzlibzm0zi6zi3zi0zm984d56bc097043d23751b719ae16f2523b51dc2e_CodecziCompressionziGZZip_decompress_info)
>>> referenced 1 more times

See https://github.com/Bodigrim/libarchive/actions/runs/7595352273/job/20687816483

@bgamari any ideas?

[bgamari]

Does cleaning your cabal store and dist-newstyle directories help? This typically arises from the compiler changing under your feet. If this helps then we should work out how this happened

[Bodigrim]

@bgamari feel free to fork my repo and rerun GitHub actions in your fork. If it helps then it has something to do with caching of environment.

I don't have a local Windows machine at the moment.

[bgamari]

I'll have a look. Thanks @Bodigrim !

[bgamari]

I can replicate the failures observed by @Bodigrim in my own workflow. Additionally, inspection of both logs confirms that there is no caching involved. Moreover, the issue is far from specific to GHC 9.4; the build fails all the way back to 8.10.7.

[bgamari]

Unfortunately, I am unable to reproduce this in any of my local test environments. These include:

• Windows 10 VM, GHC 9.4.3 using upstream bindist
• Windows 10 VM, GHC 9.4.7 installed via ghcup
• Windows 10 VM, GHC 9.8.1 installed from source
• Windows 11 VM, GHC 9.4.7 installed via ghcup

[hasufell]

@bgamari maybe because the fix has been released? https://hackage.haskell.org/package/language-c-0.9.3/changelog

[bgamari]

@bgamari maybe because the fix has been released? https://hackage.haskell.org/package/language-c-0.9.3/changelog

I was referring to the linking issues noted by @Bodigrim, which I don't believe are related to the language-c release and are still reproducible via GitHub Actions.

[Bodigrim]

Unfortunately, I am unable to reproduce this in any of my local test environments.

Apparently the issue is with Cabal 3.6.2.0. Bumping it to 3.10.2.1 fixes CI. Closing, thanks all.