On Sat, Jan 26, 2019 at 04:34:59PM -0600, Segher Boessenkool wrote: > On Thu, Jun 23, 2016 at 09:01:30PM -0700, Davide Italiano wrote: > > LLVM currently ships with a new ELF linker http://lld.llvm.org/. > > I experiment a lot with gcc and lld so it would be nice if > > -fuse-ld=lld is supported (considering the linker is now mature enough > > to link large C/C++ applications). > > > > Also, IMHO, -fuse-ld should be a generic facility which accept other > > linkers (as long as they follow the convention ld.<arg>), and should > > also support absolute path, e.g. -fuse-ld=/usr/local/bin/ld.mylinker. > > Probably outside of the scope of this patch, but I thought worth > > mentioning. > > This can never work correctly. > > The many HAVE_LD_* flags are set for the linker you are configured > against. Now normally GNU ld and Gold will be built from the same tree, > so they will be at least mostly compatible. But for some other linker > that cannot ever work. If you can choose a random linker at runtime then > the linker features the compiler is built for will almost certainly not > match those that linker has. > > You can built with --with-ld=/some/path/to/your/lld, and *that* should > work fine. But -fuse-ld=/smth/random will result in randomness.
Yes, and please do note (distros!!) that --with-ld will result in -B also not being able to specify a linker. That's a pain if you want to run the binutils ld testsuite. You'll get something like: ERROR: ************************************************************************ ERROR: Your compiler driver ignores -B when choosing ld. ERROR: You will not be testing the new ld in many of the following tests. ERROR: It seems you will be testing /usr/bin/x86_64-w64-mingw32-ld instead. ERROR: ************************************************************************ -- Alan Modra Australia Development Lab, IBM