forked from OSchip/llvm-project
da797048d9
which doesn't use that multilib. As a consequence, fix Clang's support for cross compiling environments that were relying on this quirk to ensure the correct library search path ordering. This also re-instates the new test cases from Rafael's r193528 for cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the existing test cases (they were no longer needed). This solution was the result of a lot of IRC debugging and trying to understand *exactly* what quirk was being relied upon. It took some time for me to figure out that it was the use of 'lib32' is a multilib that was throwing a wrench in the works. In case you are thinking that its silly to use a multilib of 'lib' at all, entertainingly, GCC does so as well (you can see it with the .../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of search paths (multilib followed by non-multilib) has observable (if dubious) consequences. =/ Yuck. llvm-svn: 193601 |
||
---|---|---|
.. | ||
B_opt_tree | ||
basic_android_tree | ||
basic_cross_linux_tree/usr | ||
basic_freebsd64_tree | ||
basic_freebsd_tree | ||
basic_linux_tree | ||
basic_netbsd_tree/usr/lib | ||
debian_6_mips_tree | ||
debian_multiarch_tree | ||
fake_install_tree | ||
fedora_18_tree | ||
freescale_ppc64_tree | ||
freescale_ppc_tree | ||
gcc_version_parsing1 | ||
gcc_version_parsing2 | ||
gcc_version_parsing3 | ||
gcc_version_parsing4 | ||
gentoo_linux_gcc_4.6.2_tree/usr | ||
gentoo_linux_gcc_4.6.4_tree/usr | ||
hexagon_tree | ||
mips_cs_tree | ||
mips_fsf_tree | ||
montavista_i686_tree/usr/lib/gcc/i686-montavista-linux/4.2.0 | ||
multiarch_freebsd64_tree | ||
multilib_32bit_linux_tree | ||
multilib_64bit_linux_tree | ||
prefixed_tools_tree | ||
resource_dir/lib/linux | ||
suse_10.3_ppc64_tree | ||
ubuntu_11.04_multiarch_tree | ||
ubuntu_12.04_LTS_multiarch_tree | ||
ubuntu_13.04_multiarch_tree | ||
x86-64_ubuntu_13.10 | ||
lit.local.cfg |