Properly pass the CC toolchain to cabal #1325
Conversation
haskell/private/cabal_wrapper.py.tpl
Outdated
| @@ -143,6 +143,18 @@ with tmpdir() as distdir: | |||
| "--with-hc-pkg=" + ghc_pkg, | |||
| "--with-ar=" + ar, | |||
| "--with-gcc=" + cc, | |||
| "--ghc-option=-pgmc=" + cc, | |||
There was a problem hiding this comment.
Could this re-use ghc_cc_program_args to avoid these flags diverging in future?
Using something like "%{ghc_cc_args}": repr(ghc_cc_program_args(cc)) here.
There was a problem hiding this comment.
Ah that looks good, I’ll give it a shot. Wasn’t quite sure how to best pass this down.
There was a problem hiding this comment.
I’ve tried it but just passing it on doesn’t quite work. I’m missing the find_exe logic from the python script in that case so cc points to the wrong location. I’m not really sure what to do about this. I could imagine some logic in the python script that applies find_exe to flag that don’t start with - but that seems worse than inlining the flags here. Any ideas?
There was a problem hiding this comment.
Indeed, that's unfortunate. ghc_cc_program_args just expects a string representing cc, so we could also use a place holder and fill it in on the python side. Something like this:
bzl:
"%{ghc_cc_args}": repr(ghc_cc_program_args("$CC"))
python:
] +
[ arg.replace("$CC", cc) for arg in %{ghc_cc_args} ] +
[
That's getting on the verge, but seems still better than duplicating the flags.
There was a problem hiding this comment.
Clever, I like it! I’ve made the change.
cocreature
force-pushed
the
fix-cc-toolchain
branch
from
a3d4a57 to
50d7cc2
Compare
|
The CI failure is because the |
|
This is finally working, though I've had to make a fair bit of additions, so it would be good to get someone else's review on this. |
Cabal’s with-gcc option does not apply to the cases where GHC itself calls the C compiler which actually happens all the time. We noticed this in daml and tested this patch there where it works successfully. The flags here are the same as in ghc_cc_program_args. I’m not quite sure what the best way to deduplicate this is or if this is worth doing.
The cc_wrapper removes unneeded RUNPATHs and merges redundant RUNPATHs. The corresponding logic requires the final output binary to be produced at a path from which the relative RUNPATH entries to Bazel managed dynamic libraries are valid. This change accomplishes this by building within a temporary directory that is a sibling of the final output directory.
MACH-O load commands can take the form `@rpath/some/dir/libfoo.dylib`. In that case we want to take `some/dir` into account for the runpath check.
Cabal’s with-gcc option does not apply to the cases where GHC itself
calls the C compiler which actually happens all the time. We noticed
this in daml and tested this patch there where it works successfully.
The flags here are the same as in ghc_cc_program_args. I’m not quite
sure what the best way to deduplicate this is or if this is worth
doing.