@andykluger you are absolutely correct, I forgot this when porting from my stack-based PKGBUILD. Thanks!
Doesn't this also need ghc as a makedep?
Note: Given upstream indications1 that stack builds may be downgraded in support, I'm preemptively moving the package over to building with cabal
To clarify -- the goal of this package is to statically link against the Haskell dependencies. The non-Haskell libraries (glibc, gmp) could be worked around in theory, but need a musl-based toolchain to do so. I both haven't managed to make such a toolchain work, and doubt it is useful in Arch in practice, given the binaries aren't meant for redistribution to other distros.
If someone wants to try their hand at removing these deps (and so making of them makedepends), the build invocation must be passed --ghc-options=-optl-static, and (though I haven't managed to track down how to do this) GHC must be told to compile with musl-gcc instead of gcc (this might require installing a musl-based GHC).
This might not even be easily supported with current cabal, though, see https://github.com/haskell/cabal/issues/1325
See also https://hasufell.github.io/posts/2024-04-21-static-linking.html
(This investigation was sparked by the realization that hledger-bin is fully statically linked)
@alerque thanks, noted. GHC does seem to support PIE according to its docs, so I'm not sure why no combination of flags I've tried successfully compiles PIE code (in fact, I was under the impression that that was the default, but this may be mistaken).
RELRO I have no data at all on, though - if you know of a Haskell package that manages to pass namcap's RELRO lint, I'd appreciate the pointers to see what they're doing differently.
@gesh Thanks a lot for that Haskell hackery. I was so close but blundering around not really understanding how the whole ecosystem comes together.
As the maintainer of namcap I can say authoritatively you can ignore the SHSTK business for now. I'll release a namcap update that drops that rule by default until it is better supported by compilers. I'm less familiar with Haskell and the other two lints, but they certainly aren't blockers for this package either.
Warning: namcap complains the binary lacks FULL RELRO, PIE, and GNU_PROPERTY_X86_FEATURE_1_SHSTK
Have given up on trying to silence it, but am open to suggestions for improvement.
The first appears to be generally problematic for Haskell1, and the last doesn't seem to be relevant to non-GCC applications (though this may be my ignorance speaking).
Sorry, I was dissatisfied with the hack I'd found to work around this, and was sitting on it until I could give something better.
Thankfully, the workaround I have now is much cleaner now ghc-9.6.5 has been released, so I will be releasing a working version shortly.
In brief, the issue is that the default makepkg configuration sets LDFLAGS but not LD.
GHC used to take this as its cue to select its own choice of LD.
However GHC would not check that its choice of LD supports LDFLAGS.
This is a problem for dependencies with C components, which get linked using this LD.
A fix1 for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's installed using the current ghcup HEAD (starting with 7a684ad2) will have --disable-ld-override passed, which also fixes the issue.
(In case this is relevant for the future, the original hack I was using exploited the fact that in prepare(), LDFLAGS is not marked for export, so pre-building dependencies there would avoid this bug (since user-facing packages usually don't have C components))
I fail to understand how you can build this right now. I started having trouble with my pandoc-sile-git package when trying to get it up to 3.1.13 parity and decided to see how you got around the issues. Apparently you haven't, because I get this when trying to build in a clean chroot:
configure: error: Failed to determine machine word size. Does your toolchain actually work?
