Teach the driver to not try to use 'lib32' multilib spellings on ARM

which doesn't use that multilib. As a consequence, fix Clang's support
for cross compiling environments that were relying on this quirk to
ensure the correct library search path ordering.

This also re-instates the new test cases from Rafael's r193528 for
cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the
existing test cases (they were no longer needed).

This solution was the result of a lot of IRC debugging and trying to
understand *exactly* what quirk was being relied upon. It took some time
for me to figure out that it was the use of 'lib32' is a multilib that
was throwing a wrench in the works.

In case you are thinking that its silly to use a multilib of 'lib' at
all, entertainingly, GCC does so as well (you can see it with the
.../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of
search paths (multilib followed by non-multilib) has observable (if
dubious) consequences. =/ Yuck.

llvm-svn: 193601

1 files changed, 19 insertions, 6 deletions

diff --git a/clang/lib/Driver/ToolChains.cpp b/clang/lib/Driver/ToolChains.cpp
index 1903f115b43..2a112c24925 100644
--- a/clang/lib/Driver/ToolChains.cpp
+++ b/clang/lib/Driver/ToolChains.cpp
@@ -2264,13 +2264,26 @@ static void addPathIfExists(Twine Path, ToolChain::path_list &Paths) {
 
 static StringRef getMultilibDir(const llvm::Triple &Triple,
                                 const ArgList &Args) {
-  if (!isMipsArch(Triple.getArch()))
-    return Triple.isArch32Bit() ? "lib32" : "lib64";
+  if (isMipsArch(Triple.getArch())) {
+    // lib32 directory has a special meaning on MIPS targets.
+    // It contains N32 ABI binaries. Use this folder if produce
+    // code for N32 ABI only.
+    if (hasMipsN32ABIArg(Args))
+      return "lib32";
+    return Triple.isArch32Bit() ? "lib" : "lib64";
+  }
 
-  // lib32 directory has a special meaning on MIPS targets.
-  // It contains N32 ABI binaries. Use this folder if produce
-  // code for N32 ABI only.
-  if (hasMipsN32ABIArg(Args))
+  // It happens that only x86 and PPC use the 'lib32' variant of multilib, and
+  // using that variant while targeting other architectures causes problems
+  // because the libraries are laid out in shared system roots that can't cope
+  // with a 'lib32' multilib search path being considered. So we only enable
+  // them when we know we may need it.
+  //
+  // FIXME: This is a bit of a hack. We should really unify this code for
+  // reasoning about multilib spellings with the lib dir spellings in the
+  // GCCInstallationDetector, but that is a more significant refactoring.
+  if (Triple.getArch() == llvm::Triple::x86 ||
+      Triple.getArch() == llvm::Triple::ppc)
     return "lib32";
 
   return Triple.isArch32Bit() ? "lib" : "lib64";