aboutsummaryrefslogtreecommitdiff
path: root/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2011-10-01 00:37:35 +0000
committerChandler Carruth <chandlerc@gmail.com>2011-10-01 00:37:35 +0000
commiteb86b5b039230f5bf7f5bebdc345bf6843410425 (patch)
treebb04969946dfc480cd462d9fb4138654652f98e1 /lib/Frontend/CompilerInvocation.cpp
parent5202a4d0bbd9b9a98958b2d9869e38b3f118b73c (diff)
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
Diffstat (limited to 'lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions