This bug steams off from #331623.
As ghc does not use externally any build system and calls ld directly something  should respect LDFLAGS variable. It leads to lost canary ldflags used by QA team and maybe more serious ldflags drops, used by exotic arches.
 Possible solutions are:
* Cabal-the-library can detect LDFLAGS in './Setup configure/build' phase and pass correct -optl- to ghc.
* ghc-the-binary itself can respect LDFLAGS envvar in it's internals (best runtime support)
* ghc-wrapper can thanslate LDFLAGS to -optl args with help of shell
(similar upstream ticket http://hackage.haskell.org/trac/hackage/ticket/458)
Fixed in .eclass by:
> slyfox 10/09/12 07:37:09
> Modified: haskell-cabal.eclass
> Make .cabal built haskell packages respect LDFLAGS envvar. Fixes bug #333217 (and inferior bug #335591)
The current approach is to convert environment LDFLAGS to cabal parameters for ghc: each $ldflag translates to --ghc-option=-optl$ldflag