Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to support new GHC 9.4's new Windows toolchain #8071

Merged
merged 4 commits into from
Apr 6, 2022

Conversation

bgamari
Copy link
Contributor

@bgamari bgamari commented Mar 30, 2022

As noted in GHC #21068, the lld linker used on Windows by GHC 9.4 and later does not support object merging. Consequently, --enable-library-for-ghci can no longer be supported on this platform. In this MR we:

  • turn --enable-library-for-ghci into an error on platforms where it is not supported.
  • teach Cabal to use llvm-ar's L modifier when available, which is now necessary when building static archives on Windows (since the archive may contain other archives, as noted in GHC #21068)

Please include the following checklist in your PR:

Please also shortly describe how you tested your change. Bonus points for added tests!

@bgamari
Copy link
Contributor Author

bgamari commented Mar 30, 2022

This supercedes #8062.

-- Our solution is to use "ar r" in the simple case when one call is enough.
-- When we need to call ar multiple times we use "ar q" and for the last
-- call on OSX we use "ar qs" so that it'll make the index.

let simpleArgs = case hostOS of
OSX -> ["-r", "-s"]
_ | dashLSupported -> ["-qL"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this (and will be) harmless on linux?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. I have seen no traditional use of .a archives which would want the non--L behavior; you always want the merging behavior that -L introduces. It's somewhat incredible that binutils' ar does not support it yet.

@phadej
Copy link
Collaborator

phadej commented Mar 30, 2022

General note: This issue looks like some kind of release candidate of cabal-install will be required for GHC alphas/betas/release-candidates, as it seems it won't be possible to use old cabal-install with GHC-9.4 on windows?

Is this right, @bgamari?

@bgamari
Copy link
Contributor Author

bgamari commented Apr 1, 2022

General note: This issue looks like some kind of release candidate of cabal-install will be required for GHC alphas/betas/release-candidates, as it seems it won't be possible to use old cabal-install with GHC-9.4 on windows?

Is this right, @bgamari?

Yes, sadly this is the case.

Copy link
Member

@Mikolaj Mikolaj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you.

Copy link
Member

@jneira jneira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks!
should not we backport this to 3.6?

@Mikolaj Mikolaj added merge me Tell Mergify Bot to merge and removed attention: needs-review labels Apr 6, 2022
bgamari and others added 4 commits April 6, 2022 21:31
As noted in GHC #21068, the lld linker used on Windows by GHC 9.4 and later
does not support object merging. Consequently, --enable-library-for-ghci
can no longer be supported on this platform.
As of 9.4, GHC on Windows may produce .o files that are in fact archive
files due to the lack of object merging support in the lld linker (see
GHC #21068). Consequently, we must ensure that `ar` merges input
archives' members, not add them as a single entry.
@andreabedini andreabedini force-pushed the wip/disable-ghci-libs-on-windows branch from 9eda67c to cabd857 Compare April 6, 2022 21:31
@mergify mergify bot merged commit 1304347 into haskell:master Apr 6, 2022
@jneira
Copy link
Member

jneira commented Apr 7, 2022

should not we backport this to 3.6?

i guess make 3.6 work with ghc-9.4 needs more changes and they were not already backported?

@Mikolaj
Copy link
Member

Mikolaj commented Apr 7, 2022

@bgamari: please let us know if you think we need to backport this. Until then, let's leave it be, I guess?

@bgamari
Copy link
Contributor Author

bgamari commented Apr 8, 2022

Given that users are advised to use the most recent cabal-install release with new GHC releases, I don't believe that backporting is necessary.

@Mikolaj
Copy link
Member

Mikolaj commented Apr 8, 2022

That implies we'd need to release cabal 3.8 before GHC 9.4. We'll see...

@Bodigrim
Copy link
Collaborator

Bodigrim commented May 4, 2022

Any plans for cabal RC soon? Otherwise testing of GHC 9.4-alpha1 on Windows is blocked.

@Mikolaj
Copy link
Member

Mikolaj commented May 4, 2022

I think the idea was to test a nightly build [edit: of master branch]. Do I remember correctly, @gbaz, @emilypi? Where are our nightly builds? Gitlab somewhere?

@jneira
Copy link
Member

jneira commented May 4, 2022

validate workflow generate artifacts, to do the dogfooding but they also can be downloaded, i guess we could use them: https://github.com/haskell/cabal/actions/runs/2270699540#artifacts

@Mikolaj
Copy link
Member

Mikolaj commented Jun 1, 2022

RC seems to be ready (famous last words): https://downloads.haskell.org/~cabal/cabal-install-3.8.1.0-rc1/

Please kindly test and give feedback.

@Bodigrim, @bgamari

@andreabedini
Copy link
Collaborator

andreabedini commented Jun 1, 2022

For ghcup users:

ghcup install cabal --url https://downloads.haskell.org/~cabal/cabal-install-3.8.1.0-rc1/cabal-install-3.8.0.20220526-x86_64-linux-deb10.tar.xz 3.8.0.20220526

@Mikolaj
Copy link
Member

Mikolaj commented Jun 1, 2022

@andreabedini: the "3.8.0.2022052" in your commandline seems cut off; no idea if that matters...

@andreabedini
Copy link
Collaborator

@Mikolaj that would be just a release tag for ghcup. Fixed it anyway! Thanks.

@Bodigrim
Copy link
Collaborator

Bodigrim commented Jun 1, 2022

@Mikolaj I checked cabal HEAD once this was merged, it worked fine with GHC 9.4 on Windows. I’m AFK, so cannot check the RC before next week.

@Mikolaj
Copy link
Member

Mikolaj commented Jun 1, 2022

Thank you for the confirmation. 3.8 is very close to master's HEAD and we probably haven't broken Windows GHC 9.4 support since then, so I hope we are fine.

@Mikolaj
Copy link
Member

Mikolaj commented Jun 2, 2022

The official tags have dropped; we are now committed: https://github.com/haskell/cabal/tree/cabal-install-v3.8.1.0-rc1.

erikd pushed a commit to erikd/cabal that referenced this pull request Oct 12, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Oct 24, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Oct 26, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Oct 27, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Oct 30, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Oct 31, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 3, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 5, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 5, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 6, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 6, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 6, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 6, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 6, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 7, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 7, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 12, 2023
erikd pushed a commit to erikd/cabal that referenced this pull request Nov 14, 2023
@hasufell
Copy link
Member

hasufell commented Jan 3, 2024

Given that users are advised to use the most recent cabal-install release with new GHC releases, I don't believe that backporting is necessary.

This doesn't match ghcup's policy. I'm in the process of backporting this change to 3.6.

This is the only issue I've heard about cabal-3.6 and ghc-9.4 compatibility. Are any others known?

@phadej
Copy link
Collaborator

phadej commented Jan 3, 2024

Are any others known?

Cabal-3.6 does not support GHC-9.6. Period.

It works because of happy accident (well, actually it doesn't on windows!)

If proper support to be added, then all other changes related to GHC version have to be added. (see for bare minimum https://github.com/haskell/cabal/wiki/Making-a-release#for-release-for-new-ghc-version)

In fact, GHC-3.10.2.0 support of GHC-9.8 is partial, which is unfortunate.

@hasufell
Copy link
Member

hasufell commented Jan 3, 2024

Cabal-3.6 does not support GHC-9.6. Period.

That is not an issue. I'm only interested in Cabal-3.6 + GHC-9.4.

If proper support to be added, then all other changes related to GHC version have to be added. (see for bare minimum https://github.com/haskell/cabal/wiki/Making-a-release#for-release-for-new-ghc-version)

Thanks for the pointer.

@phadej
Copy link
Collaborator

phadej commented Jan 3, 2024

That is not an issue. I'm only interested in Cabal-3.6 + GHC-9.4.

Sorry, I got versions wrong. Cabal-3.6 doesn't support GHC-9.4. (GHC-9.4 bundles Cabal-3.8).

@hasufell
Copy link
Member

hasufell commented Jan 3, 2024

That is not an issue. I'm only interested in Cabal-3.6 + GHC-9.4.

Sorry, I got versions wrong. Cabal-3.6 doesn't support GHC-9.4. (GHC-9.4 bundles Cabal-3.8).

Sure, I'm just trying to contain damage from too eagerly recommending GHC 9.4, which is mostly busted on windows due to the radical toolchain changes.

@ulysses4ever
Copy link
Collaborator

@phadej

In fact, GHC-3.10.2.0 support of GHC-9.8 is partial

What do you mean by partial exactly? The forgotten extension?

hasufell added a commit to haskell/ghcup-metadata that referenced this pull request Jan 4, 2024
Related:

* haskell/ghcup-hs#966

We bump this, although 'cabal run' is known to be broken
on windows: haskell/cabal#9334

However, backporting more patches to 3.6 is not sustainable.
Initially, I tried to backport
haskell/cabal#8071,
but it's not clear whether that is the only thing that causes
compatibility issues with GHC 9.4 and might drive us into
an awkward situation as well.
@phadej
Copy link
Collaborator

phadej commented Jan 4, 2024

The forgotten extension?

Not forgotten, but left out because unwillingness to make a major version bump release

Also I don't trust normaliseGhcArgs to do the most accurate job in presence of GHC-9.8's new warning stuff (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst). I think normaliseGhcArgs is conservative, so using new (especially warning group) flags will always cause recompilation, but maybe not.

EDIT: also https://downloads.haskell.org/ghc/latest/docs/users_guide/using-warnings.html#ghc-flag--Wcompat group has changed previously but not in 9.8 AFAIK, but as issue above, it's a minor inconsistency. It's unluckily to be hit by that.

@andreabedini
Copy link
Collaborator

Just drive by comment to notice that @hasufell is most likely interested in cabal-install (which is what GHCup distributes) and not Cabal. cabal-install can use a newer version of Cabal if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge me Tell Mergify Bot to merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants