1 files changed, 21 insertions, 5 deletions
diff --git a/ELF/Driver.cpp b/ELF/Driver.cpp
index 50b701175..4f4466a8a 100644
--- a/ELF/Driver.cpp
+++ b/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.
-  if (Args.hasArg(OPT_version) || Args.hasArg(OPT_v))
-    outs() << getLLDVersion() << "\n";
+  // 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_v) || Args.hasArg(OPT_version))
+    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;