diff options
| -rw-r--r-- | gnu/llvm/tools/lld/ELF/Driver.cpp | 24 |
1 files changed, 20 insertions, 4 deletions
diff --git a/gnu/llvm/tools/lld/ELF/Driver.cpp b/gnu/llvm/tools/lld/ELF/Driver.cpp index 3cf88e3c1ca..99253313c35 100644 --- a/gnu/llvm/tools/lld/ELF/Driver.cpp +++ b/gnu/llvm/tools/lld/ELF/Driver.cpp @@ -281,11 +281,27 @@ void LinkerDriver::main(ArrayRef<const char *> ArgsArr, bool CanExitEarly) { return; } - // GNU linkers disagree here. Though both -version and -v are mentioned - // in help to print the version information, GNU ld just normally exits, - // while gold can continue linking. We are compatible with ld.bfd here. + // Handle -v or -version. + // + // A note about "compatible with GNU linkers" message: this is a hack for + // scripts generated by GNU Libtool 2.4.6 (released in February 2014 and + // still the newest version in March 2017) or earlier to recognize LLD as + // a GNU compatible linker. As long as an output for the -v option + // contains "GNU" or "with BFD", they recognize us as GNU-compatible. + // + // This is somewhat ugly hack, but in reality, we had no choice other + // than doing this. Considering the very long release cycle of Libtool, + // it is not easy to improve it to recognize LLD as a GNU compatible + // linker in a timely manner. Even if we can make it, there are still a + // lot of "configure" scripts out there that are generated by old version + // of Libtool. We cannot convince every software developer to migrate to + // the latest version and re-generate scripts. So we have this hack. if (Args.hasArg(OPT_version) || Args.hasArg(OPT_v)) - outs() << getLLDVersion() << "\n"; + outs() << getLLDVersion() << " (compatible with GNU linkers)\n"; + + // ld.bfd always exits after printing out the version string. + // ld.gold proceeds if a given option is -v. Because gold's behavior + // is more permissive than ld.bfd, we chose what gold does here. if (Args.hasArg(OPT_version)) return; |