Revert r140604: "Let -B work for ld paths on Linux."

This patch may do what it describes, it may not. It's hard to tell as
its completely unclear what this is supposed to do. There are also no
test cases. More importantly, this seems to have broken lots of linker
invocations on multilib Linux systems.

The manual pages for 'ld' on Linux mention translating a '=' at the
beginning of the path into a *configure time* sysroot prefix (this is,
I believe, distinct from the --sysroot flag which 'ld' also can
support). I tested this with a normal binutils 'ld', a binutils 'ld'
with the sysroot flag enabled, and gold with the sysroot flag enabled,
and all of them try to open the path '=/lib/../lib32', No translation
occurs.

I think at the very least inserting an '=' needs to be conditioned on
some indication that it is supported and desired. I'm also curious to
see what toolchain and whan environment cause it to actually make
a difference.

I'm going to add a test case for basic sanity of Linux 'ld' invocations
from Clang in a follow-up commit that would have caught this.

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

diff --git a/lib/Driver/ToolChains.cpp b/lib/Driver/ToolChains.cpp
index 306be65ed48688ab82690bcf52f8102c85bbaf7b..91699c3d057573c5cfb7abe6736bed0eea1e6b9f 100644 (file)
--- a/lib/Driver/ToolChains.cpp
+++ b/lib/Driver/ToolChains.cpp
@@ -1712,8 +1712,8 @@ Linux::Linux(const HostInfo &Host, const llvm::Triple &Triple)
   // FIXME: This is in here to find crt1.o. It is provided by libc, and
   // libc (like gcc), can be installed in any directory. Once we are
   // fetching this from a config file, we should have a libc prefix.
-  Paths.push_back("=/lib/../" + Lib);
-  Paths.push_back("=/usr/lib/../" + Lib);
+  Paths.push_back("/lib/../" + Lib);
+  Paths.push_back("/usr/lib/../" + Lib);
 
   if (!Suffix.empty())
     Paths.push_back(Base);