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

Reply via email to