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

Cabal incorrectly constructs libHSrts library path #7763

Closed
bgamari opened this issue Oct 20, 2021 · 12 comments · Fixed by #7764
Closed

Cabal incorrectly constructs libHSrts library path #7763

bgamari opened this issue Oct 20, 2021 · 12 comments · Fixed by #7764

Comments

@bgamari
Copy link
Contributor

bgamari commented Oct 20, 2021

Describe the bug

A recent GHC bug (#20520) brought to light the fact that Cabal includes knowledge of internal implementation details of GHC (specifically, the particular file name of libHSrts). This appears to have been introduced by 382143a and 1c07f83.

This naming is unstable and has indeed changed in recent releases, hence the ghc#20520.

@bgamari
Copy link
Contributor Author

bgamari commented Oct 20, 2021

It's quite unclear to me why Cabal is trying to compute the name of libHSrts. It should rather be depending upon GHC's -flink-rts flag to instruct GHC to choose the correct RTS itself.

@bgamari
Copy link
Contributor Author

bgamari commented Oct 20, 2021

I see the reason: -flink-rts is actually a somewhat new flag (introduced in 9.0). I think the solution here is to teach Cabal to rely on this flag when available. Linking is a tricky thing and only GHC has the information to manage it robustly. We should avoid making Cabal responsible for it.

@fgaz
Copy link
Member

fgaz commented Oct 20, 2021

Does this mean Cabal is unusable with ghc post-#20520?

@bgamari
Copy link
Contributor Author

bgamari commented Oct 20, 2021

Cabal is currently unable to build foreign libraries with GHC 9.0 or 9.2.

@Mikolaj
Copy link
Member

Mikolaj commented Oct 20, 2021

I guess this implies cabal-install 3.6.3 (or at least Cabal 3.6.3).

Edit: scratch that, we seem not to be ready for GHC 9.0 for other reasons: #7747.

@Mikolaj
Copy link
Member

Mikolaj commented Jan 29, 2022

@bgamari: any news? #7747 is nearing completion, so soon we should be able to test foreign libraries with master branch.

@Bodigrim
Copy link
Collaborator

Bodigrim commented Feb 1, 2022

@bgamari it would be nice to fix this in time for GHC 9.2.2, otherwise Windows users are likely to be stuck with GHC 8.10 indefinitely.

@Bodigrim
Copy link
Collaborator

@Mikolaj could Cabal maintainers please take the lead in resolving this?

@Mikolaj Mikolaj removed the 3.8 label Apr 19, 2022
@Mikolaj Mikolaj added this to the Considered for 3.8 milestone Apr 19, 2022
@Mikolaj
Copy link
Member

Mikolaj commented Apr 19, 2022

Easily said. Let me beg @bgamari some more... :)

@Bodigrim
Copy link
Collaborator

@Mikolaj see https://gitlab.haskell.org/ghc/ghc/-/issues/20520#note_411402, I believe Ben can use help from the core team.

@mergify mergify bot closed this as completed in #7764 Apr 22, 2022
jneira added a commit to jneira/cabal that referenced this issue Apr 24, 2022
mergify bot pushed a commit that referenced this issue Apr 25, 2022
* Unmark foreign lib test as broken for win

It seems #7764 fixed the test, but the pr was merged without
having the ci green

* Add changelog for #7763, #7764 and #8111
@hasufell
Copy link
Member

hasufell commented May 7, 2023

Which Cabal (library) version includes this fix?

@Kleidukos
Copy link
Member

@hasufell according to GH the PR (#7764) is included in 3.8.1.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants