-
Notifications
You must be signed in to change notification settings - Fork 710
lib:Cabal - do not use GHC to configure LD. #10970
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
base: master
Are you sure you want to change the base?
lib:Cabal - do not use GHC to configure LD. #10970
Conversation
Huh. I wonder if this would solve a problem an OI user was having trying to get things to work a few months ago; it was failing around where you described. https://matrix.to/#/!pAORzwKXYKXnnMpVxT:matrix.org/$yryJoFP9O1XxKDT9E93xKjmuWnMLBCqqkDo0EIrT9Zc?via=matrix.org&via=kf8nh.com&via=tchncs.de |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise looks good.
7b4eec4
to
a9c4539
Compare
Interesting, sadly most of the pastebins are now unavailable. 🤷♂️ |
So is the user, AFAICT. |
Cabal uses a peculiar c program to check if LD supports and should use -x. To do this, it shells out to GHC to compiler the C file. This however requires that GHC will not bail out, yet cabal does not pass --package-db flags to this GHC invocation, and as such we can run into situations where GHC bails out, especially during GHC bootstrap phases where not all boot packages are available. We however do not need GHC to compiler a c program, and can rely on the C compiler. Fundamentally cabal does not allow modelling program dependencies in the program db, as such we must configure gcc first before using it. We make a small change to lib:Cabal (specifically the GHC module, and it's Internal companion) to allow it to configure gcc first, before trying to configure ld, and thus having gcc in scope while configuring ld. This removes the need for the awkward ghc invocation to compiler the test program. Co-authored-by: brandon s allbery kf8nh <[email protected]>
a9c4539
to
fc00402
Compare
The testsuite-failure is actually quite interesting:
|
You could fix the testsuite failure by moving the It seems a bit dubious generally that |
Is there a ticket number corresponding to this change? |
I don't believe so, although the CONTRIBUTING guidelines state:
https://github.com/haskell/cabal/blob/master/CONTRIBUTING.md#pull-requests--issues |
Cabal uses a peculiar c program to check if LD supports and should use -x. To do this, it shells out to GHC to compiler the C file. This however requires that GHC will not bail out, yet cabal does not pass --package-db flags to this GHC invocation, and as such we can run into situations where GHC bails out, especially during GHC bootstrap phases where not all boot packages are available.
We however do not need GHC to compiler a c program, and can rely on the C compiler.
Fundamentally cabal does not allow modelling program dependencies in the program db, as such we must configure gcc first before using it.
We make a small change to lib:Cabal (specifically the GHC module, and it's Internal companion) to allow it to configure gcc first, before trying to configure ld, and thus having gcc in scope while configuring ld. This removes the need for the awkward ghc invocation to compiler the test program.
E.g. the PR only touches documentation or tests, does refactorings, etc.
Include the following checklist in your PR: