Gold linker fails

changed weight to 5

Following fixes it:

diff --git a/bronze-linker.cabal b/bronze-linker.cabal
index 548dbb9..00e0b5b 100644
--- a/bronze-linker.cabal
+++ b/bronze-linker.cabal
@@ -31,6 +31,8 @@ executable bronze-linker-exe
   build-depends:       base
                      , bronze-linker
   default-language:    Haskell2010
+  ghc-options:       -optl-fuse-ld=gold
+  ld-options:        -fuse-ld=gold

 test-suite bronze-linker-test
   type:                exitcode-stdio-1.0
Discard this hunk from worktree [y,n,q,a,d,/,e,?]? y

@domenkozar Ok, now I added the project https://github.com/ksaric/bronze-linker-client to try out. It depends on the project https://github.com/ksaric/bronze-linker and it doesn't compile.

Also, I added three branches to the original project in question:

demo/failing-example
demo/working-counter-example
demo/full-working

You can see that when using gold linker in the executable only, things work correctly - demo/working-counter-example.

I'm not sure this is intentional, and I thought it's connected to the **actual bug I found, which is when you try to compile a project that has a dependency that uses gold linker, the aforementioned error occurs** - you can reproduce that with the project I added - https://github.com/ksaric/bronze-linker-client.

I hope this is clearer, and yes, I'm confused as well, this is kind of strange.

So here's my understanding when bug happens on GHC 8.0.2:

If library A is linked with gold and library B depends on A, no matter if B is specified to be linked with gold or not, B fails to detect that it should use the gold linker.

Gold linking is defined in cabal as:

  ghc-options:       -optl-fuse-ld=gold
  ld-options:        -fuse-ld=gold

It appears that library B is compiled with linker flags for ld, as if gold linker wasn't used:

    *** Linker:
    /nix/store/wgvrkijby0awhqkyfkj0qp9cc4921hd9-gcc-wrapper-5.4.0/bin/cc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -Wl,
-rpath,/nix/store/shv5yba4ns4ax38gvrd36rfynm9yms4i-ghc-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -Wl,-rpath,/home/ielectric/dev/bronze-linker-client/.stack-work/install/x86_64-linux-nix/lts-8.17/8.0.
2/lib/x86_64-linux-ghc-8.0.2 -Wl,-rpath,/nix/store/1m0qhsb5ppq0zslv5np65lp0f63cznp5-stack-1.3.2/lib -Wl,-rpath,/nix/store/9lhgvxka8m162d5db0my5cd4qpjii9sv-git-2.12.0/lib -Wl,-rpath,/nix/stor
e/y0czf1y7s6zb7ld3hla4av8qcz8rsb0g-cabal-install-1.24.0.2/lib -Wl,-rpath,/nix/store/shv5yba4ns4ax38gvrd36rfynm9yms4i-ghc-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 -Wl,-rpath,/nix/store/shv5yba4ns
4ax38gvrd36rfynm9yms4i-ghc-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 -Wl,-rpath,/nix/store/886fjp4lpi05x5iilqdc9g01ji85qmp7-gmp-6.1.1/lib -Wl,-rpath,/nix/store/shv5yba4ns4ax38gvrd36rfynm9yms4i
-ghc-8.0.2/lib/ghc-8.0.2/rts -o .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/libHSbronze-linker-client-0.1.0.0-K8pX0ycmvusCn3mv2VVqE7-ghc8.0.2.so -shared -Wl,-Bsymbolic -Wl,-h,libH
Sbronze-linker-client-0.1.0.0-K8pX0ycmvusCn3mv2VVqE7-ghc8.0.2.so .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/Lib.dyn_o -L/nix/store/1m0qhsb5ppq0zslv5np65lp0f63cznp5-stack-1.3.2/li
b -L/nix/store/9lhgvxka8m162d5db0my5cd4qpjii9sv-git-2.12.0/lib -L/nix/store/y0czf1y7s6zb7ld3hla4av8qcz8rsb0g-cabal-install-1.24.0.2/lib -L/home/ielectric/dev/bronze-linker-client/.stack-work
/install/x86_64-linux-nix/lts-8.17/8.0.2/lib/x86_64-linux-ghc-8.0.2 -L/nix/store/1m0qhsb5ppq0zslv5np65lp0f63cznp5-stack-1.3.2/lib -L/nix/store/9lhgvxka8m162d5db0my5cd4qpjii9sv-git-2.12.0/lib
 -L/nix/store/y0czf1y7s6zb7ld3hla4av8qcz8rsb0g-cabal-install-1.24.0.2/lib -L/nix/store/shv5yba4ns4ax38gvrd36rfynm9yms4i-ghc-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -L/nix/store/shv5yba4ns4ax38gvrd3
6rfynm9yms4i-ghc-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 -L/nix/store/886fjp4lpi05x5iilqdc9g01ji85qmp7-gmp-6.1.1/lib -L/nix/store/shv5yba4ns4ax38gvrd36rfynm9yms4i-ghc-8.0.2/lib/ghc-8.0.2/ghc
-prim-0.5.0.0 -L/nix/store/shv5yba4ns4ax38gvrd36rfynm9yms4i-ghc-8.0.2/lib/ghc-8.0.2/rts -lHSbronze-linker-0.1.0.0-BILiaGIWwdu7BJxyS5cPx-ghc8.0.2 -lHSbase-4.9.1.0-ghc8.0.2 -lHSinteger-gmp-1.0
.0.1-ghc8.0.2 -lHSghc-prim-0.5.0.0-ghc8.0.2 -lgmp '-fuse-ld=gold'

Right. And if you try to explicitly add gold linker flags to library B, it doesn't help, since GHC thinks (heh, I wish) that it doesn't need to use gold linker for project A, even if the project A has defined gold linker explicitly.

Anyone can try to modify the project https://github.com/ksaric/bronze-linker-client with the flags and without them, and **it will fail in both cases**.

So:

project A is using gold linker
project B is using project A

''Project B can't compile because it's sending parameters for "regular" ld, and not gold linker.''

Trac metadata

Trac field	Value
CC	- → domen.kozar@iohk.io

I'm looking at the example described in the ticket summary:

The issue here is that the library component was registered with (quoting ghc-pkg dump),

ld-options: -fuse-ld=gold

Consequently, when we go to link the executable GHC will add this flag to its usual link flags, the latter of which assume that we are using BFD ld.

Frankly, I don't see any better way to handle this beyond just teaching GHC to use ld when possible. I'm working on this (see #13541 (closed)) but unfortunately it isn't likely that this will make the already-terribly-late 8.2.1. We may be able to work it in to 8.2.2 if we hear very vocal support from users, however.

Replying to [ticket:13810#comment:138374 bgamari]:

beyond just teaching GHC to use ld when possible

Do you mean gold?

Consequently, when we go to link the executable GHC will add this flag to its usual link flags, the latter of which assume that we are using BFD ld.

I don't quite understand this. Isn't the key problem here that the concept of the "ld program" and the "ld-options" are unhealthily mixed up?

It seems to me that if one could explicitly distinguish "I want this linker" and "I want these ld-flags", the problem wouldn't exist, because then the choice of linker would not be propagated through ld-options.

In other words, isn't the problem here that we're linking through the compiler (e.g. gcc) instead of the actual linker binary? Because otherwise we'd not even be using the -fuse-ld flag.

(Another workaround might be to make ghc ignore the -fuse-ld flag as a flag that can traverse ld-options through build-depends, but that option seems more hacky than linking directly with a linker executable, if that is possible.)

Do you mean gold?

Whoops, yes.

I don't quite understand this. Isn't the key problem here that the concept of the "ld program" and the "ld-options" are unhealthily mixed up?

In other words, isn't the problem here that we're linking through the compiler (e.g. gcc) instead of the actual linker binary? Because otherwise we'd not even be using the -fuse-ld flag.

I've played around with the idea of involing ld ourselves and have concluded that it's almost certainly going to hurt more than it helps. Linking tends to be terribly platform specific and rather difficult to get right (see also: gcc -dumpspecs). Moreover, linkers on many platforms tend to be, shall we say, quirky. I don't see us being able to robustly implement the logic necessary to drive the linker as well as gcc.

Keep in mind that GHC is not only responsible for linking Haskell; we are often asked to link against native code, some of which may require peculiar linking behavior (e.g. one of those many rules seen in gcc -dumpspecs). This isn't to say that gcc's abstraction over linking is quite perfect; far from it. However, it's IMHO much better than having to dive into the muck ourselves.

Moreover, I don't think thinking ourselves would necessarily help the crux of this problem: the user essentially gave us conflicting linking options. Really, the user shouldn't have to give us *any* linker options in this case; ghc should just handle linker choice for you.

closed

changed milestone to %8.2.1

We have decided that we will merge the fix #13541 (closed) for 8.2.1, so there should be no need to pass ld flags like this in the future.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedWon'tFix

Ok, great, thanks!

mentioned in commit 625143f4

mentioned in issue #13958

added Pnormal label

Trac field	Value
Version	8.0.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

Gold linker fails

Child items 0

Activity

Gold linker fails

Relates to

Activity