[PATCH 0 of 3] Add support for using gold instead of ld

Yann E. MORIN yann.morin.1998@anciens.enib.fr
Tue Dec 28 23:02:00 GMT 2010

Arnaud, Bryan, All,

On Tuesday 28 December 2010 20:31:04 Arnaud Lacombe wrote:
> That said, it would seem that the default linker depends. As I'd
> understand it so far, gcc maintain its own set of tools in its
> internal directory structure (the one containing "as", "ld", ...) use
> them to access the actual linker.

I am not sure I understand this. Are you talking about a combined tree?
We are not using a combined tree, and gcc does not have the source for
as, ld gold, or [...] in its tree.

But yet, when we build the 'core' gcc, we copy binutils' tools into the
core gcc install dir, so that it can find them.

> It looks it can be overridden by the
> DEFAULT_LINKER configure time environment variable (accessible at
> configure time through the --with-ld=bla switch).

Yes, it can be overriden at configure time. I've used it once, because I
wanted to catch all calls to ld, so I ./configured gcc to use my wrapper
instead of the real ld, and that wrapper was calling the real ld after
loggign the call. It was in an environment where I could not easily pass
-v -Wl,-verbose to gcc (with stupid specific build system not using
Makefiles... Sigh...)

> More info seem to be available in gcc/collect2.c, more specifically
> the part of main() after "Try to discover a valid linker/nm/strip to
> use." around line 1300.

All I could extract from there is that nothing is added after the 'ld' part.

> > LTO is in gcc 4.5 and greater, and it just so happens that binutils
> > gained support for building linker plugins in 2.21...
> AFAIK, LTO does not make the linker plugin mandatory.

Indeed no. If the linker can't use the plugins (eg. because it's not gold)
then collect2 will do the job, albeit with less coverage. See:

> > Maybe specific versions of binutils should be paired with specific
> > versions of gcc.
> Unless proven otherwise, I am doubtful, that would be a huge regression.

Indeed, that would be...

Yann E. MORIN.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

For unsubscribe information see http://sourceware.org/lists.html#faq

More information about the crossgcc mailing list