Bug 209817 – [CMake] Disable gold linker on MIPS

• Status: NEW
• Component: WPE WebKit

[Carlos Alberto Lopez Perez]

It seems gold linker can't be used on MIPS

/home/igalia/clopez/yocto/builds/qemumips-32/tmp/work/mips32r2-poky-linux/wpewebkit/2.28.0-r0/recipe-sysroot-native/usr/bin/mips-poky-linux/../../libexec/mips-poky-linux/gcc/mips-poky-linux/9.3.0/ld.gold: error: .gnu.hash is incompatible with the MIPS ABI
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.


See also: https://github.com/Igalia/meta-webkit/pull/154

[Carlos Alberto Lopez Perez]

Created attachment 395068 [details]
Patch

[Konstantin Tokarev]

Won't -Wl,--hash-style,sysv fix the issue on MIPS?

[Konstantin Tokarev]

It seems like there was similar issue with ld.bfd in the past [1] and setting hash style manually was known to work it around

[1] https://bugs.gentoo.org/233233

[Adrian Perez]

(In reply to Konstantin Tokarev from comment #2)
> Won't -Wl,--hash-style,sysv fix the issue on MIPS?

If this works, it would be a better option IMO.

[Carlos Alberto Lopez Perez]

It seems the issue its more complex than I though initially.
Thanks Konstantin for the pointers that lead me to investigate this further.

This is a summary of my understanding so far:

* First, if you are not familiar with the different hash-styles then check this great post that explains very good why using --hash-style=gnu its preferred to hash-style=sysv: https://flapenguin.me/elf-dt-gnu-hash

* MIPS has not supported --has-style=gnu for years, but recently that has changed and now binutils support --has-style=gnu for MIPS but only with the bfd linker. The gold linker doesn't support it.

* Yocto distribution has decided to default to use --has-style=gnu for MIPS (which its great), but they didn't disabled the gold linker in the binutils build for MIPS. So they are shipping a broken gold linker for MIPS (which its not great).

* When they found problems on recipes failing to build with the gold linker (like WebKit, that defaults to use the gold linker if available) they have patched those recipes to not use gold.

* I think that instead of doing that, they should have fixed the problem in the source by disabling gold in the binutils build for MIPS. I have complained about this here: https://github.com/Igalia/meta-webkit/pull/154#issuecomment-606865641

So, I don't this patch I proposed here its right.
Neither I'm sure anymore this its something we want to do anything about upstream.

[Konstantin Tokarev]

Right now our configuration test for gold just checks that -fuse-ld=gold is accepted by compiler and, for some reason unclear to me, checks output of `ld.gold --version` [1]. I think this should be changed to proper compilation test, using check_cxx_compiler_flag() like we do for other compiler flags. In this case, test program will be linked, and we'll be able to determine if gold is actually usable [2].

Note that linking error could be caught by other unrelated compilation tests, e.g. WebKitCompilerFlags, but OptionsCommon.cmake is run after all tests, preceding only port-specific options.


[1] Is any system or toolchain known for faking ld.gold? And what's the issue if ld.gold is not really GNU gold? Do we really need to ignore it in this case?

[2] Similar check should be done for lld, which IMO should be used as a preferred option over gold iif it is usable for given compilation target.

[Carlos Alberto Lopez Perez]

(In reply to Konstantin Tokarev from comment #6)
> Right now our configuration test for gold just checks that -fuse-ld=gold is
> accepted by compiler and, for some reason unclear to me, checks output of
> `ld.gold --version` [1]. I think this should be changed to proper
> compilation test, using check_cxx_compiler_flag() like we do for other
> compiler flags. In this case, test program will be linked, and we'll be able
> to determine if gold is actually usable [2].
> 

I like this idea.


> Note that linking error could be caught by other unrelated compilation
> tests, e.g. WebKitCompilerFlags, but OptionsCommon.cmake is run after all
> tests, preceding only port-specific options.
> 
> 
> [1] Is any system or toolchain known for faking ld.gold? And what's the
> issue if ld.gold is not really GNU gold? Do we really need to ignore it in
> this case?
> 

I'm not aware of any system faking ld.gold

> [2] Similar check should be done for lld, which IMO should be used as a
> preferred option over gold iif it is usable for given compilation target.

Indeed, it seems lld its even faster than gold: https://lld.llvm.org/#performance

Are you aware of any drawbacks or issues by using lld with GCC?

[Konstantin Tokarev]

(In reply to Carlos Alberto Lopez Perez from comment #7)
> Are you aware of any drawbacks or issues by using lld with GCC?

Seems to work just fine, though I haven't test it much yet.

[Carlos Alberto Lopez Perez]

It seems the gold linker can be problematic and the binaries it generates are less optimized than when using bfd. See: https://github.com/Igalia/meta-webkit/pull/167#issuecomment-614970184

Maybe we should only default to using gold (or ldd) for developer builds.