ld-options are passed to GCC when linking hsc2hs object files
#8824
Comments
|
Need some people who understand linker and ffi issues well to comment here. @bgamari @mpickering |
|
Friendly bump |
|
Running into this again 😞 So another bump? |
NicolasT
added a commit
to NicolasT/landlock-hs
that referenced
this issue
Mar 31, 2024
On some platforms, building a `hsc2hs` program requires `libgcc`, and on some platforms, `libgcc` uses `sigfillset`. For some reason (a bug, I'd say), `cabal` passes `ld-options` to the compiler when building the generated C file. In our case, this causes `sigfillset` to be wrapped (which is desired for the actual `psx` library), but since `__wrap_sigfillset` is never defined, the build fails. This work-around tells `hsc2hs` to include a small C file in its generated sources which defines `__wrap_sigfillset` as a proxy for `__real_sigfillset`. See: haskell/cabal#8824
NicolasT
added a commit
to NicolasT/landlock-hs
that referenced
this issue
Mar 31, 2024
On some platforms, building a `hsc2hs` program requires `libgcc`, and on some platforms, `libgcc` uses `sigfillset`. For some reason (a bug, I'd say), `cabal` passes `ld-options` to the compiler when building the generated C file. In our case, this causes `sigfillset` to be wrapped (which is desired for the actual `psx` library), but since `__wrap_sigfillset` is never defined, the build fails. This work-around tells `hsc2hs` to include a small C file in its generated sources which defines `__wrap_sigfillset` as a proxy for `__real_sigfillset`. This requires the Cabal format to be bumped to 3.6. See: haskell/cabal#8824
NicolasT
added a commit
to NicolasT/landlock-hs
that referenced
this issue
Mar 31, 2024
On some platforms, building a `hsc2hs` program requires `libgcc`, and on some platforms, `libgcc` uses `sigfillset`. For some reason (a bug, I'd say), `cabal` passes `ld-options` to the compiler when building the generated C file. In our case, this causes `sigfillset` to be wrapped (which is desired for the actual `psx` library), but since `__wrap_sigfillset` is never defined, the build fails. This work-around tells `hsc2hs` to include a small C file in its generated sources which defines `__wrap_sigfillset` as a proxy for `__real_sigfillset`. This requires the Cabal format to be bumped to 3.6. See: haskell/cabal#8824
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It appears that, when a
libraryspecifies someld-options, theseld-optionsare passed togccwhen it's invoked to link some object files generated as part of some the pipeline to turn ahscfile into ahsfile, i.e., when the C code generated byhsc2hs(which should output the finalhsfile) gets linked.This is counter-intuitive, and (IMHO) incorrect: any
ld-optionsset by somelibraryshould be used to link said library into some Haskell executable, not whenhsc2hsis used by some project to link thehsc2hs-generated program.In my case, my library specifies
-Wl,-wrap,sigfillsetasld-options, and the library itself does provide the (then required)__wrap_sigfillsetsymbol. However, when-Wl,-wrap,sigfillsetis passed to thegccinvocation of thehsc2hspipeline, on some platforms, build fails since my library is not linked into the generator executable (and indeed, it should not be). This leaves__wrap_sigfillsetundefined, which on some platforms is OK (if there's no reference), but on some platforms it's not (there,libgccseems to usesigfillsetinternally).Looking at the failing command (see below), I wonder whether most of these options should be used when linking the
hsc2hsgenerator program at all: this program should not use any Haskell libraries at all, so why should all paths to Haskell libraries be passed in (-L...), andrpaths set (-Wl,-R,...), or link againstlibdlorlibgmpsimply because the RTS or, e.g.,ghc-bignumwould rely on this if they were linked in?To reproduce, clone https://github.com/NicolasT/landlock-hs.git, checkout tag
psx-0.1.1.1and runcabal test psx-teston some system exposing the issue, e.g., in thedocker.io/haskell:9.2-slimcontainer image.The issue can not be reproduced on Fedora 36, or in the
buildpack-deps:jammycontainer image (which is used in the package CI).Cabal version: 3.8.1.0 (in the
docker.io/haskell:9.2-slimcontainer image)GHC version: 9.2.6 (in the
docker.io/haskell:9.2-slimcontainer image)GCC version: 8.3.0 (in the
docker.io/haskell:9.2-slimcontainer image)Error output when running in `docker.io/haskell:9.2-slim`, formatted for readability
Note how
which are the
ld-optionsset by thepsxlibrary are passed through, which should not be the case.The text was updated successfully, but these errors were encountered: