333217 – Cabal built binaries do not respect LDFLAGS variable

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

Importance:	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 (RETIRED)
Modified:	2010-09-12 07:47 UTC (History)
CC List:	0 users

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

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