[Linux] Gold linker should not be the default system linker

[Lei Zhang]

Hi Folks,

Google's Linux kernel team has found several cases where the gold
linker does not correctly link kernel modules, resulting in computers
that do not start up correctly. Thus it it recommended that Chromium
developers who previously ran install-build-deps.sh and set gold as
/usr/bin/ld undo this change:

1. Sync src/build/install-build-deps.sh to r100802.
2. Run src/build/install-build-deps.sh again:
- install-build-deps.sh will ask you to restore /usr/bin/ld.orig to /usr/bin/ld
- install-build-deps.sh will re-install gold to /usr/local/gold/bin,
with ld.bfd as well so NaCl links correctly.
3. To continue using gold in future builds, you need to set the CXX
environment variable to "g++ -B/usr/local/gold/bin".
- e.g. CXX="g++ -B/usr/local/gold/bin" make BUILDTYPE=Debug chrome
- TODO: Add a gyp flag so developers don't have to do this manually.
http://crbug.com/96358

If you run into any issues, please let me know.

- Lei

[Mike Frysinger]

On Mon, Sep 12, 2011 at 20:05, Lei Zhang wrote:
> 3. To continue using gold in future builds, you need to set the CXX
> environment variable to "g++ -B/usr/local/gold/bin".
> - e.g. CXX="g++ -B/usr/local/gold/bin" make BUILDTYPE=Debug chrome

upstream gcc-4.5+ and Debian's (and Goobuntu's) gcc-4.4+ support
-fuse-ld=gold (in CFLAGS/CXXFLAGS) so that you dont have to go
touching /usr/bin/ld ...
-mike

[Evan Martin]

How does that find gold? The version shipped by Ubuntu doesn't work,
so we'd need it to find our build of it.

[Mike Frysinger]

On Tue, Sep 13, 2011 at 12:53, Evan Martin wrote:

> On Tue, Sep 13, 2011 at 6:43 AM, Mike Frysinger wrote:
>> On Mon, Sep 12, 2011 at 20:05, Lei Zhang wrote:
>>> 3. To continue using gold in future builds, you need to set the CXX
>>> environment variable to "g++ -B/usr/local/gold/bin".
>>> - e.g. CXX="g++ -B/usr/local/gold/bin" make BUILDTYPE=Debug chrome
>>
>> upstream gcc-4.5+ and Debian's (and Goobuntu's) gcc-4.4+ support
>> -fuse-ld=gold (in CFLAGS/CXXFLAGS) so that you dont have to go
>> touching /usr/bin/ld ...
>
> How does that find gold?  The version shipped by Ubuntu doesn't work,
> so we'd need it to find our build of it.

it should search $PATH for `gold`

also, i was semi-mistaken. i thought this went upstream, but it seems
it never made it out of Debian. so only Debian/Ubuntu/Goobuntu will
support this option.
-mike

[Lei Zhang]

On Tue, Sep 13, 2011 at 10:26 AM, Mike Frysinger <vap...@chromium.org> wrote:
> On Tue, Sep 13, 2011 at 12:53, Evan Martin wrote:
>> On Tue, Sep 13, 2011 at 6:43 AM, Mike Frysinger wrote:
>>> On Mon, Sep 12, 2011 at 20:05, Lei Zhang wrote:
>>>> 3. To continue using gold in future builds, you need to set the CXX
>>>> environment variable to "g++ -B/usr/local/gold/bin".
>>>> - e.g. CXX="g++ -B/usr/local/gold/bin" make BUILDTYPE=Debug chrome
>>>
>>> upstream gcc-4.5+ and Debian's (and Goobuntu's) gcc-4.4+ support
>>> -fuse-ld=gold (in CFLAGS/CXXFLAGS) so that you dont have to go
>>> touching /usr/bin/ld ...
>>
>> How does that find gold?  The version shipped by Ubuntu doesn't work,
>> so we'd need it to find our build of it.
>
> it should search $PATH for `gold`

I don't see how that works. Most binutils-gold packages install gold
as /usr/bin/ld. e.g.
http://packages.debian.org/squeeze/i386/binutils-gold/filelist

[Mike Frysinger]

On Tue, Sep 13, 2011 at 14:32, Lei Zhang wrote:

yes, the older binutils releases did that. they've moved on to
installing in parallel (ld.bfd and ld.gold). so to make things work
with the older releases on Debian/Goobuntu, you'd have to undo the
ld->ld.bfd-link diversion manually.
-mike

[Ben Smith]

>>>>> 3. To continue using gold in future builds, you need to set the CXX
>>>>> environment variable to "g++ -B/usr/local/gold/bin".

You can also use:

PATH=/usr/local/gold/bin:$PATH make or ninja...

I found that this was easier to use with the goma/ninja/gold builds discussed in another thread:

PATH=/path/to/goma:/usr/local/gold/bin:$PATH path/to/ninja/ninja -C out/Release -j 200 chrome

[Wez]

I found that that doesn't work; g++ still seems to insist on using /usr/bin/ld for me; are the compiler search paths not distinct from the normal ones?

Cheers,

Wez

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Albert J. Wong (王重傑)]

Yes...the gcc toolchain actually knows where it is installed on the filesystem.

  http://gcc.gnu.org/faq.html#gas

It actually takes quite a bit of pain to make a gcc/binutils set that's can be moved into random places on the filesystem.  I think this is done to allow multiple binutils and compilers on one system (eg., when cross-compiling) where different "as" or "ld" binaries would be mutually incompatible.

IMO, using -B to inform gcc et al., that the binary search path needs to be modified is probably the cleanest/safest solution.

-Albert

[Evan Martin]

On Wed, Sep 14, 2011 at 11:00 AM, Albert J. Wong (王重傑)
<ajw...@chromium.org> wrote:
> Yes...the gcc toolchain actually knows where it is installed on the
> filesystem.
>   http://gcc.gnu.org/faq.html#gas
> It actually takes quite a bit of pain to make a gcc/binutils set that's can
> be moved into random places on the filesystem.  I think this is done to
> allow multiple binutils and compilers on one system (eg., when
> cross-compiling) where different "as" or "ld" binaries would be mutually
> incompatible.
> IMO, using -B to inform gcc et al., that the binary search path needs to be
> modified is probably the cleanest/safest solution.

This seems to do what I'd want:

$ export PATH=`pwd`:$PATH
$ echo 'exit 1' >> ld; chmod +x ld
$ echo 'int main() {}' > test.c
$ gcc test.c
collect2: ld returned 1 exit status

Unfortunately, if goma is providing that gcc, it doesn't work right.
I am not clear on how goma decides which ld to run. (I tried
restarting goma after modifying my path but it still found the wrong
one.)

[Ben Smith]

That's the same issue I had -- the order of goma and gold in PATH seems to matter:

PATH=/usr/local/gold/bin:/path/to/goma:$PATH ...

doesn't work, but

PATH=/path/to/goma:/usr/local/gold/bin:$PATH ...

works. For me, anyway.

[Wez]

I had the paths the other way around, by mistake - with them swapped as below, things work fine for me.  :)

--

[Fumitoshi Ukai (鵜飼文敏)]

when running local gcc, goma will drop paths from PATH before a path where gomacc exists (to avoid recursively calling gomacc).

So, put goma's path first in PATH.

You can check it on /compilerz page of compiler_proxy.

Thanks,

ukai

[Szymon Jakubczak]

> Google's Linux kernel team has found several cases where the gold> linker does not correctly link kernel modules, resulting in computers> that do not start up correctly.

Apologies for reviving an old thread, but I think it's worth
mentioning that although some might not think that they link kernel
modules, a binary video driver update with gold might make X unusable:
https://bugs.launchpad.net/ubuntu/maverick/+source/nvidia-graphics-drivers/+bug/607399

tl;dr: If you get kernel oops after a recent driver update, restore
ld.bfd as default linker, then re-install the driver modules.

--Szymon

[Daniel Cheng]

For those who aren't as familiar with Linux (like me), the stanza you want to invoke after updating /usr/bin/ld to point to ld.bfd is:

sudo apt-get --reinstall install nvidia-current

Out of curiosity, if /usr/bin/ld isn't pointing at ld.gold, is there still a way to build Chrome using gold?

Daniel

[Wez]

See Ben's mail earlier in this thread; basically using:

PATH=/path/to/goma:/usr/local/gold/bin:$PATH

and exporting that in your environment should do the trick.  Rebuilds of kernel components as root won't pick that up, so they'll still use the standard ld.

Wez