Bug 333217

Summary:	Cabal built binaries do not respect LDFLAGS variable
Product:	Gentoo Linux	Reporter:	Sergei Trofimovich (RETIRED) <slyfox>
Component:	New packages	Assignee:	Gentoo's Haskell Language team <haskell>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
URL:	http://hackage.haskell.org/trac/hackage/ticket/458
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:	335591
Bug Blocks:	331933

Description Sergei Trofimovich (RETIRED) 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 (RETIRED) 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