Go to file
Chandler Carruth 69a125bf02 Fix using Clang as a cross compiler installed on a host machine and not
inside of a sysroot targeting a system+sysroot which is "similar" or
"compatible" with the host system. This shows up when trying to build
system images on largely compatible hardware as-if fully cross compiled.

The problem is that previously we *perfectly* mimiced GCC here, and it
turns out GCC has a bug that no one has really stumbled across. GCC will
try to look in thy system prefix ('/usr/local' f.ex.) into which it is
instaled to find libraries installed along side GCC that should be
preferred to the base system libraries ('/usr' f.ex.). This seems not
unreasonable, but it has a very unfortunate consequence when combined
with a '--sysroot' which does *not* contain the GCC installation we're
using to complete the toolchain. That results in some of the host
system's library directories being searched during the link.

Now, it so happens that most folks doing stuff like this use
'--with-sysroot' and '--disable-multilib' when configuring GCC. Even
better, they're usually not cross-compiling to a target that is similar
to the host. As a result, searching the host for libraries doesn't
really matter -- most of the time weird directories get appended that
don't exist (no arm triple lib directory, etc). Even if you're
cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling
multilib makes it less likely that you'll actually find viable libraries
on the host. But that's just luck. We shouldn't rely on this, and this
patch disables looking in the system prefix containing the GCC
installation if that system prefix is *outside* of the sysroot. For
empty sysroots, this has no effect. Similarly, when using the GCC
*inside* of the sysroot, we still track wherever it is installed within
the sysroot and look there for libraries. But now we can use a cross
compiler GCC installation outside the system root, and only look for the
crtbegin.o in the GCC installation, and look for all the other libraries
inside the system root.

This should fix PR12478, allowing Clang to be used when building
a ChromiumOS image without polluting the image with libraries from the
host system.

llvm-svn: 154176
2012-04-06 16:32:06 +00:00
clang Fix using Clang as a cross compiler installed on a host machine and not 2012-04-06 16:32:06 +00:00
compiler-rt [ASan] move replacements for new/delete to separate file 2012-04-06 08:21:08 +00:00
debuginfo-tests Revert previous patch as the corresponding clang patch was reverted. 2012-01-26 07:01:33 +00:00
libclc Switch to BSD/MIT dual license. 2012-02-22 04:47:39 +00:00
libcxx Fix the remaining atomic tests, all of which were wrong for the case where a 2012-04-05 13:48:16 +00:00
libcxxabi I would really like to write the handlers in terms of C++11 atomics. This would give us the best performance, portablity, and safety tradeoff. Unfortunately I can not yet do that. So I've put the desired code in comments, and reverted the handler getters to the slower but safer legacy atomic intrinsics. 2012-03-19 16:56:51 +00:00
lld Remove trailing whitespace. 2012-04-03 18:40:27 +00:00
lldb Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running". 2012-04-06 02:17:47 +00:00
llvm Make GVN's propagateEquality non-recursive. No intended functionality change. 2012-04-06 15:31:09 +00:00
polly Fix a bug introduced by r153739: We are not able to provide the correct 2012-04-06 03:56:27 +00:00