Try to unbreak the FreeBSD toolchain's detection of 32-bit targets

inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.

Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148981 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 3 insertions, 3 deletions

diff --git a/lib/Driver/ToolChains.cpp b/lib/Driver/ToolChains.cpp
index 44f51e4c5d..c39d624346 100644
--- a/lib/Driver/ToolChains.cpp
+++ b/lib/Driver/ToolChains.cpp
@@ -1627,11 +1627,11 @@ Tool &OpenBSD::SelectTool(const Compilation &C, const JobAction &JA,
 FreeBSD::FreeBSD(const Driver &D, const llvm::Triple& Triple)
   : Generic_ELF(D, Triple) {
 
-  // When targeting 32-bit platforms, look for '/usr/lib32' first and fall back
-  // to '/usr/lib' for the remaining cases.
+  // When targeting 32-bit platforms, look for '/usr/lib32/crt1.o' and fall
+  // back to '/usr/lib' if it doesn't exist.
   if ((Triple.getArch() == llvm::Triple::x86 ||
        Triple.getArch() == llvm::Triple::ppc) &&
-      llvm::sys::fs::exists(getDriver().SysRoot + "/usr/lib32"))
+      llvm::sys::fs::exists(getDriver().SysRoot + "/usr/lib32/crt1.o"))
     getFilePaths().push_back(getDriver().SysRoot + "/usr/lib32");
   else
     getFilePaths().push_back(getDriver().SysRoot + "/usr/lib");