Pass *-options to GHC when compiling ordinary Haskell sources by zlonast · Pull Request #10969 · haskell/cabal

zlonast · 2025-05-22T16:23:54Z

Will close issues #9801 #4435
Main idea #9801 (comment)

IMHO, cc-options (and ld-options and cpp-options and ...) should be always passed when invoking GHC, similarly as ghc-options should be always used when invoking ghc - regardless of what is the intention of a particular GHC-call. GHC might use or not use the options, Cabal cannot know and should not guess.

cc-options, cxx-options, jspp-options, asm-options, cmm-options, ld-options, cpp-options,
should be always passed when invoking GHC, similarly as ghc-options should be always used when
invoking ghc - regardless of what is the intention of a particular GHC-call.
GHC might use or not use the options, Cabal cannot know and should not guess.

cc-options and cxx-options still need to be separated (C/C++) for versions below 8.10.
https://gitlab.haskell.org/ghc/ghc/-/issues/16477

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

Patches conform to the coding conventions.
Any changes that could be relevant to users have been recorded in the changelog.
- Is the change significant? If so, remember to add significance: significant in the changelog file.
The documentation has been updated, if necessary.
Manual QA notes have been included.
Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

Depends-on: #11711
Depends-on: #11713

zlonast · 2025-05-22T17:54:50Z

I probably need to think about tests, maybe something started working besides CApiFFI 🤔

zlonast · 2025-05-22T18:12:29Z

~~Ok, this only works for things newer than 8.8~~
~~gcc: fatal error: cannot specify ‘-o’ with ‘-c’, ‘-S’ or ‘-E’ with multiple files~~

Ok, got it, we just need to separate the flags -optc and -optcxx
Pass -optcxx for GHC >= 8.10 #7072

zlonast · 2025-05-24T17:04:23Z

@ulysses4ever @phadej It's not very easy to add flags to sources files due to backward compatibility, so for now I suggest considering the pull request as is ¯\_(ツ)_/¯ (Anyway, this solved the problem with macros in header files)

ulysses4ever

Great start, thank you! Below are some inline questions.

One general question: did you check that this doesn't lead to duplicated options when cabal calls GHC? I assume other *-options are passed today sometimes. So, sometimes we'll get those options passed as today and through your change too. Is that right? It seems undesirable.

It's not very easy to add flags to sources files due to backward compatibility

Can you be more specific? Do you mean it's hard to test on older GHCs? This shouldn't be a problem because the tests can run for specific versions of GHC (e.g. starting from 8.10).

geekosaur

Same concerns as @ulysses4ever raised.

phadej · 2025-05-24T19:39:44Z

did you check that this doesn't lead to duplicated options when cabal calls GHC?

Yes, it looks like so.

I'd say the problem is rather that GhcOptions is not used uniformly. There is e.g. componentCcGhcOptions which does set ghcOptCcOptions. Why these don't show up when compiling files CApiFFI headers?

IMHO, it's wrong that there are separate componentAsmGhcOptions, componentJsGhcOptions, componentGhcOptions. There should be just one componentGhcOptions with all the options, and then it's up to GHC which ones are relevant, and which aren't.

EDIT: There might be situations where ghcOptMode or something like that is different, and input files "obviously". But the bulk of options should be the same. Starting with verbosity. I'd imagine there is only single line in the codebase which does ghcOptVerbosity = toFlag (min verbosity normal). Currently there are six copies of that. Cannot be right. I suspect there are many subtle inconsistencies hiding because of that.

EDIT: So AFAICT, this is not the correct fix, not what I'd imagine seeing.

geekosaur

There are a lot of unresolved comments still, that will need to be resolved to merge.

geekosaur · 2026-01-23T15:55:58Z

FWIW I'm not worried about rebases, except insofar as they may help with development; since PRs are being merged all the time, it's usually not worth the resulting constant rebases when Mergify will do it itself.

ulysses4ever · 2026-01-23T16:11:08Z

@zlonast please, attend to the inline comments when you get a chance

zlonast · 2026-01-24T04:50:40Z

I've closed a few threads because I don't think they're that important, but feel free to reopen them.

phadej
Ok, I see. The GHC-8.8 doesn't know about C++ compiler, so we have to deal with it separately, and in an ugly way.

Could you write a note, referencing the test. By looking at the code only, it looks wrong or at least suspicious.

In the retrospective, cabal-install could refused to support an accidental "but it did work before with older GHC, cc-options were passed to C compiler" when proper cxx-options were added. Those accidents just make code base very spagetti.

zlonast
in some reality it is true, but due to problems with linking on versions lower than 9.4, I just don't know what to do

https://gitlab.haskell.org/ghc/ghc/-/issues/17919

I think this is the main part from which the problems grow, the issue itself is about dynamic linking, but I could not find where and how the static one was fixed

zlonast · 2026-01-24T04:57:16Z

Perhaps we should add more tests, but I don't have the energy for that right now.

ulysses4ever
Could you, at least, check that the test suite has tests for all the other-language options (ASM, JS, CXX, CMM, LD)? And if some of these options don't have tests, could you add something simple for them? I agree that it's not fun to do this exercise, but I think it's a big change and I want at least a minimal guarantee that we're not breaking things badly.

zlonast
cc-options - cabal-testsuite/PackageTests/FFI/ForeignOptsC/README.md
cxx-options - cabal-testsuite/PackageTests/FFI/ForeignOptsCxx/README.md
jspp-options - cabal-testsuite/PackageTests/JS/JSPPOptions/README.md
asm-options - none
cmm-options - cabal-testsuite/PackageTests/Cmm/CmmSources/README.md
ld-options - ParserTests
cpp-options - ParserTests
-pgmc - cabal-testsuite/PackageTests/ShowBuildInfo/Complex
-O1 and -O2 for C++ and C and Asm - cabal-testsuite/PackageTests/ShowBuildInfo/Complex

if it still reproduces we should start tests for asm-options and -pgmc/-pgma #6534

zlonast · 2026-01-24T05:02:37Z

There are some linking issues with older versions. I don't know what to say about that.

      , -- there are problems with linking with versions below 9.4,
       -- that's why we need this replacement for linkGhcOptions
       -- see example in cabal-testsuite/PackageTests/ShowBuildInfo/Complex
       ghcOptCcProgram = Internal.defaultGhcOptCcProgram lbi
mpickering
What "problems with linking" and what exact issue does this solve? It's quite mysterious at the moment.

phadej
Agree, these kinds of comments should include links to GHC issues

This is not https://gitlab.haskell.org/ghc/ghc/-/issues/17919, as that one is pre GHC-8.10

zlonast
I still don't know where it was fixed, my search methods were weak. I only know that it happened with the release 9.4.*

zlonast · 2026-01-24T05:38:23Z

And also we have problems with normalizer. #11187 (comment)

zlonast
the real problem is that when adding -pgm* flags we need to write at least 5(10) tests instead of one because the output contains the path to the C compiler

no -pgmc
single-2.out
single-2.test.hs

gcc is /usr/bin/gcc
single.out
single.test.hs

clang is /tools/ghc-<GHCVER>/lib/../mingw/bin/clang
win-single-4.out
win-single-4.test.hs

clang is /ghcup/ghc/<GHCVER>/lib/../mingw/bin/clang
win-single-8-6.out
win-single-8-6.test.hs

clang is /ghcup/ghc/<GHCVER>/lib/../mingw//bin/clang
win-single.out
win-single.test.hs

geekosaur
That sounds more like a bug / deficiency in the normalizer to me.

Mikolaj · 2026-02-02T16:36:06Z

I see the diff is quite large and there is scope creep (possible interactions, hypothetical scenarios, related buglets), so I'm worried for the kind PR author. Could we all try to help somehow? Maybe let's try to answer some questions @zlonast poses? Could we somehow split responsibility for some subtasks or open new tickets for them and leave them undone for now? It would be really great to merge this PR while there still the momentum.

ulysses4ever · 2026-02-02T16:39:25Z

The only unresolved thread that I was able to find in this (rather lengthy) discussion is this: #10969 (comment) started by @mpickering, so, maybe Matt could try to push it forward (or backward :-))

Mikolaj · 2026-03-26T18:57:42Z

Sadly, @mpickering may not be able to contribute to this PR any more. @zlonast: how can we help to get it through?

zlonast · 2026-03-26T19:53:29Z

@Mikolaj Hi! As the author, I think it works and we can be merge it 😄

But perhaps you want to pay attention to this:

The GCC issue: We want to explicitly pass the GCC path, but for versions < 9.4, it causes linking failures for reasons I haven't been able to isolate yet.
Lack of tests: I haven't implemented tests for the new flag options yet.

ulysses4ever · 2026-03-27T17:23:05Z

@zlonast thank you for your work here and for the summary in partiular. Quetsions:

The GCC issue: We want to explicitly pass the GCC path, but for versions < 9.4, it causes linking failures for reasons I haven't been able to isolate yet.

This looks rather serious. Can you elaborate with example scenarios? E.g. will I not be able to build any package with c-sources after this change if I need to use 9.4?

FTR, we are supposed to maintain ccompatibility with any GHC released last 5 years. GHC 9.4.8 was released 10 November 2023, so there's still 2.5 years of it staying in this support window.

Lack of tests: I haven't implemented tests for the new flag options yet.

Do you think you could add some?

zlonast · 2026-04-07T15:48:34Z

This must happen before this pull request is merged.

The GCC issue: We want to explicitly pass the GCC path, but for versions < 9.4, it causes linking failures for reasons I haven't been able to isolate yet.

issue #11712

pr fix #11713

Lack of tests: I haven't implemented tests for the new flag options yet.

tests #11711

zlonast · 2026-04-08T10:29:23Z

-optc-O2,-optcxx-O2,-opta-O2 into a separate pull request #11716

zlonast · 2026-04-08T14:34:16Z

I found the problem and left a link in this #10969 (comment).

I've only left two things in that pr.

the solution itself
code refactoring [significance: significant]

I suggest checking the compilation of the entire clc-stackage again before merging.

mergify · 2026-05-14T09:57:08Z

Deprecation notice: This pull request comes from a fork and was rebased using bot_account impersonation. This capability will be removed on July 1, 2026. After this date, the rebase action will no longer be able to rebase fork pull requests with this configuration. Please switch to the update action/command to ensure compatibility going forward.

mergify · 2026-05-14T09:57:08Z

rebase

✅ Branch has been successfully rebased

Refactor componentGhcOptions for pass *-options to all invoking GHC. During the refactoring process we needed to add componentGhcOptions to all Haskell sources. It was also worth add linkGhcOptions to linkLibrary same as componentGhcOptions to linkExecutable, linkFLib. Add test for PackageTests/FFI/ForeignOptsCapi to pass cc-options flags to *.h. Fixes haskell#9801 haskell#4435 Co-authored-by: Mikolaj Konarski <mikolaj.konarski@gmail.com>

Co-authored-by: Yuriy Syrovetskiy <git-orbi@cblp.su>

zlonast · 2026-05-17T10:37:02Z

To summarize the current state of this PR:

All previous discussions have been resolved.
All prerequisite PRs have been merged.
Tests are written and passing.

Regarding the tests, the two added test cases directly address what was requested in the linked issues (#9801, #4435):

The first test ForeignOptsCapi demonstrates that the flags now successfully reach the linking objects.
The second test ForeignSourceTemplateHaskell shows the flexibility of our approach: everything works as expected even within TemplateHaskell.

@Mikolaj @ulysses4ever I believe this is now ready.

ulysses4ever · 2026-05-17T12:39:43Z

+    ( \verbosity lbi bi clbi odir filename ->
+        (Internal.sourcesGhcOptions verbosity lbi bi clbi odir filename)
+          { -- C++ compiler options: GHC >= 8.10 requires -optcxx, older requires -optc
+            -- we want to be able to support cxx-options and cc-options separately
+            -- https://gitlab.haskell.org/ghc/ghc/-/issues/16477
+            -- see example in cabal-testsuite/PackageTests/FFI/ForeignOptsCxx
+            ghcOptCcOptions =
+              Internal.ghcOptionsSince
+                (mkVersion [8, 10])
+                (compiler lbi)
+                (Internal.optimizationCFlags lbi ++ ccOptions bi)
+          , -- Use -pgmc to ensure that Cabal always passes cc-options, ld-options to GHC (#4435, #9801)
+            -- We can only do this on GHC >= 9.4, as we need https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6949
+            -- Without that GHC MR, this change would cause GHC to never pass -no-pie when linking,
+            -- which can cause breakage depending on the C toolchain use. Otherwise,
+            -- we pass the flag only to source files #11712
+            -- see example in cabal-testsuite/PackageTests/FFI/ForeignOptsPgmc
+            ghcOptCcProgram = maybeToFlag $ programPath <$> lookupProgram gccProgram (withPrograms lbi)
+          }
+    )


Is this an absolute duplicate of the hunk above? Can we factor it out? At the very least, I don't think we should duplicate comments that long. You could create a "Note" and reference it. (We don't use notes as extensively as GHC, but there are some cases where we do.)

Then I propose what is in the last commit

ulysses4ever · 2026-05-17T12:44:22Z

+              (Internal.sourcesGhcOptions (verbosityLevel verbosity) lbi bnfo clbi odir filename)
+                { -- C++ compiler options: GHC >= 8.10 requires -optcxx, older requires -optc
+                  -- we want to be able to support cxx-options and cc-options separately
+                  -- https://gitlab.haskell.org/ghc/ghc/-/issues/16477
+                  -- see example in cabal-testsuite/PackageTests/FFI/ForeignOptsCxx
+                  ghcOptCcOptions =
+                    Internal.ghcOptionsSince
+                      (mkVersion [8, 10])
+                      (compiler lbi)
+                      (Internal.optimizationCFlags lbi ++ ccOptions bnfo)
+                , -- Use -pgmc to ensure that Cabal always passes cc-options, ld-options to GHC (#4435, #9801)
+                  -- We can only do this on GHC >= 9.4, as we need https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6949
+                  -- Without that GHC MR, this change would cause GHC to never pass -no-pie when linking,
+                  -- which can cause breakage depending on the C toolchain use. Otherwise,
+                  -- we pass the flag only to source files #11712
+                  -- see example in cabal-testsuite/PackageTests/FFI/ForeignOptsPgmc
+                  ghcOptCcProgram = maybeToFlag $ programPath <$> lookupProgram gccProgram (withPrograms lbi)
+                }


ulysses4ever · 2026-05-17T12:44:36Z

+              (Internal.sourcesGhcOptions (verbosityLevel verbosity) lbi bnfo clbi tmpDir filename)
+                { -- C++ compiler options: GHC >= 8.10 requires -optcxx, older requires -optc
+                  -- we want to be able to support cxx-options and cc-options separately
+                  -- https://gitlab.haskell.org/ghc/ghc/-/issues/16477
+                  -- see example in cabal-testsuite/PackageTests/FFI/ForeignOptsC
+                  ghcOptCxxOptions =
+                    Internal.ghcOptionsSince
+                      (mkVersion [8, 10])
+                      (compiler lbi)
+                      (Internal.optimizationCFlags lbi ++ cxxOptions bnfo)
+                , -- Use -pgmc to ensure that Cabal always passes cc-options, ld-options to GHC (#4435, #9801)
+                  -- We can only do this on GHC >= 9.4, as we need https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6949
+                  -- Without that GHC MR, this change would cause GHC to never pass -no-pie when linking,
+                  -- which can cause breakage depending on the C toolchain use. Otherwise,
+                  -- we pass the flag only to source files #11712
+                  -- see example in cabal-testsuite/PackageTests/FFI/ForeignOptsPgmc
+                  ghcOptCcProgram = maybeToFlag $ programPath <$> lookupProgram gccProgram (withPrograms lbi)
+                }


ulysses4ever · 2026-05-17T13:08:36Z

+Before `ghc` 8.10, `cc-options` and `cxx-options` were passed via one flag `-optc`,
+then in 8.10 they started to split into `-optc` and `-optcxx`, cabal picked up
+this change and started to give flags separately not only for new versions,
+but also for old ones. That is, now for 8.8 we send `-optc` flags separately for
+different sources.


Suggested change

Before `ghc` 8.10, `cc-options` and `cxx-options` were passed via one flag `-optc`,

then in 8.10 they started to split into `-optc` and `-optcxx`, cabal picked up

this change and started to give flags separately not only for new versions,

but also for old ones. That is, now for 8.8 we send `-optc` flags separately for

different sources.

Before GHC 8.10, Cabal passed its `cc-options` and `cxx-options` via one GHC flag `-optc`.

GHC 8.10 introduced `-optcxx`, and Cabal picked up this change: `cc-options` and `cxx-options` are now mapped to `-optc` and `-optcxx` respectively.

But Cabal also changed its behaviour for older GHCs (8.8 and older): Cabal sends `cc-options` and `cxx-options` through separate instances of `-optc`.

Does this sound right? I think it's a bit more clear.

Actually, changelog may be not the best place to put historical notes. Can you move it to commit message or/and comments?

For Changelog, it would be relevant to comment on compatibility with GHCs pre 9.4. Does this patch change anything for thise? I still don't quite understand those comments about 9.4 in the sources.

Yes, you're right, I just redid the comment.

-- We pass -pgmc to ensure that GHC respects cc-options and ld-options (#4435, #9801). -- However, we deliberately restrict this flag ONLY to C and C++ source files. -- We do not pass it globally (e.g., during linking or ordinary Haskell compilation) -- for two reasons: -- 1. Status quo: This preserves Cabal's historical behavior. -- 2. GHC < 9.4 bug (https://gitlab.haskell.org/ghc/ghc/-/issues/15319): Before GHC 9.4, -- passing a custom C compiler via -pgmc caused GHC to automatically disable the -- -no-pie flag (which is critical during linking on auto-hardened toolchains). -- Passing -pgmc globally would therefore break linking on older GHCs. -- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6949 fixed this by moving -- the -no-pie check to -pgml, but scoping -pgmc exclusively to C/C++ compilation -- protects older GHC versions from this link-time breakage.

Before GHC 8.10, Cabal passed both `cc-options` and `cxx-options` via a single GHC flag, `-optc`. When GHC 8.10 introduced `-optcxx`, Cabal picked up this change: `cc-options` and `cxx-options` are now mapped to `-optc` and `-optcxx`, respectively. However, Cabal also changed its behavior for older GHC versions (8.8 and below): it now sends `cc-options` and `cxx-options` through separate instances of `-optc`. Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>

zlonast force-pushed the options-invoking-ghc branch 2 times, most recently from 1bd501e to c3e68be Compare May 22, 2025 17:02

zlonast marked this pull request as ready for review May 22, 2025 17:52

zlonast added this to the Considered for 3.16 milestone May 22, 2025

zlonast force-pushed the options-invoking-ghc branch 10 times, most recently from a439429 to 1b8e5bb Compare May 24, 2025 15:33

zlonast requested review from mpickering, phadej and ulysses4ever May 24, 2025 17:05

ulysses4ever reviewed May 24, 2025

View reviewed changes

Comment thread changelog.d/pr-10969.md

Comment thread changelog.d/pr-10969.md Outdated

Comment thread cabal-testsuite/PackageTests/FFI/ForeignOptsCapi/README.md

ulysses4ever added the attention: needs-review label May 24, 2025

This was linked to issues May 24, 2025

cc-options do not get passed to GHC #4435

Open

Cabal doesn't pass cc-options to GHC when compiling ordinary Haskell sources #9801

Open

geekosaur requested changes May 24, 2025

View reviewed changes

phadej reviewed May 24, 2025

View reviewed changes

Comment thread Cabal/src/Distribution/Simple/GHC/Internal.hs Outdated

zlonast force-pushed the options-invoking-ghc branch 3 times, most recently from 0b74992 to 37417aa Compare May 28, 2025 16:26

geekosaur approved these changes Jan 23, 2026

View reviewed changes

Comment thread cabal-testsuite/PackageTests/ShowBuildInfo/Complex/win-single.test.hs Outdated

Comment thread Cabal/src/Distribution/Simple/GHC/Internal.hs Outdated

Comment thread changelog.d/pr-10969.md Outdated

Comment thread changelog.d/pr-10969.md Outdated

zlonast force-pushed the options-invoking-ghc branch from a7f3e55 to a8f1b13 Compare January 24, 2026 05:19

zlonast force-pushed the options-invoking-ghc branch from a8f1b13 to 6b7957c Compare March 27, 2026 10:48

zlonast force-pushed the options-invoking-ghc branch from 6b7957c to e522b12 Compare April 7, 2026 14:53

zlonast force-pushed the options-invoking-ghc branch from e522b12 to afa91a2 Compare April 8, 2026 10:27

zlonast force-pushed the options-invoking-ghc branch from afa91a2 to 858d618 Compare April 8, 2026 10:43

zlonast changed the title ~~Pass *-options and -pgmc gcc to GHC when compiling ordinary Haskell sources~~ Pass *-options to GHC when compiling ordinary Haskell sources Apr 8, 2026

zlonast force-pushed the options-invoking-ghc branch from 858d618 to 7de85b7 Compare April 8, 2026 12:27

zlonast mentioned this pull request May 13, 2026

GHC as a Stateless Black Box #11822

Open

4 tasks

zlonast and others added 2 commits May 17, 2026 12:54

add test for foreign source in TemplateHaskell

db14107

Co-authored-by: Yuriy Syrovetskiy <git-orbi@cblp.su>

ulysses4ever approved these changes May 17, 2026

View reviewed changes

Conversation

zlonast commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zlonast commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zlonast commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zlonast commented May 24, 2025

Uh oh!

ulysses4ever left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

geekosaur left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

phadej commented May 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

geekosaur left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

geekosaur commented Jan 23, 2026

Uh oh!

ulysses4ever commented Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zlonast commented Jan 24, 2026

Uh oh!

zlonast commented Jan 24, 2026

Uh oh!

zlonast commented Jan 24, 2026

Uh oh!

zlonast commented Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mikolaj commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ulysses4ever commented Feb 2, 2026

Uh oh!

Mikolaj commented Mar 26, 2026

Uh oh!

zlonast commented Mar 26, 2026

Uh oh!

ulysses4ever commented Mar 27, 2026

Uh oh!

zlonast commented Apr 7, 2026

Uh oh!

zlonast commented Apr 8, 2026

Uh oh!

zlonast commented Apr 8, 2026

Uh oh!

mergify Bot commented May 14, 2026

Uh oh!

mergify Bot commented May 14, 2026

✅ Branch has been successfully rebased

Uh oh!

zlonast commented May 17, 2026

Uh oh!

ulysses4ever May 17, 2026

Choose a reason for hiding this comment

Uh oh!

zlonast May 18, 2026

Choose a reason for hiding this comment

Uh oh!

ulysses4ever May 17, 2026

Choose a reason for hiding this comment

Uh oh!

ulysses4ever May 17, 2026

zlonast commented May 22, 2025 •

edited

Loading

zlonast commented May 22, 2025 •

edited

Loading

zlonast commented May 22, 2025 •

edited

Loading

phadej commented May 24, 2025 •

edited

Loading

ulysses4ever commented Jan 23, 2026 •

edited

Loading

zlonast commented Jan 24, 2026 •

edited

Loading

Mikolaj commented Feb 2, 2026 •

edited

Loading

zlonast May 18, 2026 •

edited

Loading