forked from OSchip/llvm-project
7f8042c8f3
Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466 |
||
|---|---|---|
| .. | ||
| Action.cpp | ||
| CC1AsOptions.cpp | ||
| CMakeLists.txt | ||
| Compilation.cpp | ||
| Driver.cpp | ||
| DriverOptions.cpp | ||
| InputInfo.h | ||
| Job.cpp | ||
| Makefile | ||
| Phases.cpp | ||
| SanitizerArgs.h | ||
| Tool.cpp | ||
| ToolChain.cpp | ||
| ToolChains.cpp | ||
| ToolChains.h | ||
| Tools.cpp | ||
| Tools.h | ||
| Types.cpp | ||
| WindowsToolChain.cpp | ||