Bug 52982 - add option to select particular linker
Summary: add option to select particular linker
Status: RESOLVED DUPLICATE of bug 55470
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-13 20:16 UTC by Frank Ch. Eigler
Modified: 2020-02-10 00:41 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2012-04-13 20:16:11 UTC 
If one has both ld and gold installed, gcc gives little help in letting someone choose one or the other for a particular link job.  (Systemwide relinking a la alternatives(1), or forcing creation of a temporary -B directory, are not convenient.)

Please consider adding an option to the driver, akin to -Wl... to allow overriding of the ld binary being invoked.  Perhaps: gcc -Wl=/bin/ld.gold
(and similar options for -Wa=, -Wp= could make sense).
Comment 2 Eric Gallager 2015-04-07 17:10:36 UTC 
While this report seems to be just talking about switching between ld.bfd and gold, I'd appreciate it if the linker switching could be done more generically, to support more linkers besides just those two. For example, on my current system (darwin), my copy of gcc is configured to use the ld64 installed by my package manager by default. Besides this linker, I also have several other linkers to choose between:

* the system ld64, which is an older version than the default ld64 installed by my package manager
* several other versions of ld64, each with a version suffix appended to the name of its binary (i.e. "ld-97", "ld-127", "ld-136", and "ld-latest")
* the old cctools ld, installed as "ld_classic"
* the GNU binutils/bfd ld, installed with binaries prefixed with the letter "g" (so "gld" and "gld.bfd")

My case is probably a little extreme, as I doubt the average user will have this many linkers installed, but it still serves as an example of the variety of linkers that exist out there.

Oh, and also, while I'm here, I figure I might as well add a personal example of a practical effect that this issue can have: today, I was running into an error codesigning the copy of gdb that I just built, because the linker that my copy of gcc used generated load commands that were newer than what my system codesigning utilities understood. I tried wrangling the codesigning stuff in a few different ways, but it would have been easier if I could have just told gcc to use the system linker instead of the one it had been configured with...
Comment 3 H.J. Lu 2015-04-07 21:19:17 UTC 
Dup.

*** This bug has been marked as a duplicate of bug 55470 ***
Comment 4 Fangrui Song 2020-02-10 00:41:35 UTC 
I posted a patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00510.html to make -fuse-ld=linker generic (absolute path or ld.linker)