Replying to [comment:5 angerman]:
I'm also a bit confused why gcc would not respect the LD env var.
I guess this may be controversial, but I have always liked the fact that cabal and GHC rely as little as possible on environment variables.
It has made it much easier many times for me to debug ghc issues (funnily, especially the linker investigation) because I can see all relevant inputs to a ghc invocation simply in `ps` or `strace`, and re-run
#13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): Replying to [comment:11 nh2]: them to isolate problems without accidentally not replicating the environment correctly. My personal issue with not respecting env variables is that, without respecting the environment, one has to - have explicit flags for each possible configuration value, that otherwise would have been taken from the environment. - by not using the environment, one is posed to break tooling that depends on the environment. GHC already has a lot of logic to find tools at configuration time and store their paths. `FIND_LD` already tries to detect gold, (and fails for the android toolchain...) I am much more in favor of doing tool checking rather than magic. What I mean is this: instead of trying hard to find some tool (say ld), use $LD. However if we know we want gold, try `$LD --version` to verify it actually *is* gold. And if it's not, put out a warning that $LD is not set to `gold` and that this is known not to work. However if you want to ignore the error pass `--compat-warning-only`. Which would then print a warning:
Warning: linker ($LD) does not seem to be gold. Continuing anyway due to --compat-warning-only.
instead of
Error: linker ($LD) does not seem to be gold. bfd is known not to work. To continue anyway, pass --compat-warning-only.
Then again, this makes me wonder why we test for gold, and not against bfd in the first place? Why force gold, if lld is fine as well, when all we want is to make sure we don't use a buggy/broken/slow linker called bfd? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13541#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler