Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 333217 - Cabal built binaries do not respect LDFLAGS variable
Summary: Cabal built binaries do not respect LDFLAGS variable
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Haskell Language team
URL: http://hackage.haskell.org/trac/hacka...
Whiteboard:
Keywords:
Depends on: 335591
Blocks: ldflags
  Show dependency tree
 
Reported: 2010-08-17 19:29 UTC by Sergei Trofimovich
Modified: 2010-09-12 07:47 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Trofimovich gentoo-dev 2010-08-17 19:29:05 UTC
This bug steams off from #331623.

As ghc does not use externally any build system and calls ld directly something [1] should respect LDFLAGS variable. It leads to lost canary ldflags used by QA team and maybe more serious ldflags drops, used by exotic arches.

[1] 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)
Comment 1 Sergei Trofimovich gentoo-dev 2010-09-12 07:47:00 UTC
Fixed in .eclass by:

> slyfox      10/09/12 07:37:09
> 
>   Modified:             haskell-cabal.eclass
>   Log:
>   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