For some regression tests the path to the right toolchain is specified
using the -sysroot switch. However, if clang was configured with a
custom gcc toolchain (either by using GCC_INSTALL_PREFIX in cmake or the
equivalent configure command), the path to the custom gcc toolchain path
takes precedence to the one specified by sysroot. This causes several
regression tests to fail as they will be using an unexpected path. This
patch fixes this issue by adding --gcc-toolchain='' to all tests that
rely on that. The empty string causes the driver to pick the path from
sysroot instead.
This patch contain the same kind of fixes as done in rC225182
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@339112 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The lib paths are not correctly picked up for OpenEmbedded sysroots (like arm-oe-linux-gnueabi) for 2 reasons:
1. OpenEmbedded sysroots are of the form <sysroot>/usr/lib/<triple>/x.y.z. This form is handled in clang but only for Freescale vendor.
2. 64-bit OpenEmbedded sysroots may not have a /usr/lib dir. So they cannot find /usr/lib64 as it is referenced as /usr/lib/../lib64 in clang.
This is a follow-up to the llvm patch: D48861
Reviewers: dlj, rengolin, fedor.sergeev, javed.absar, hfinkel, rsmith
Reviewed By: rsmith
Subscribers: rsmith, kristof.beyls, cfe-commits
Differential Revision: https://reviews.llvm.org/D48862
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338294 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335809 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
1. Find GCC's LDPATH from the actual GCC config file.
2. Avoid picking libraries from a similar named tuple if the exact
tuple is installed.
Reviewers: mgorny, chandlerc, thakis, rnk
Reviewed By: mgorny, rnk
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D45233
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@329512 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the gcc-config code to support multilib gcc installs properly. This
solves two problems: -mx32 using the 64-bit gcc directory (due to matching
installation triple), and -m32 not respecting gcc-config at all (due to
mismatched installation triple).
In order to fix the former issue, split the multilib scan out of
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple() (the code
is otherwise unchanged), and call it for each installation found via
gcc-config.
In order to fix the latter issue, split the gcc-config processing out of
Generic_GCC::GCCInstallationDetector::init() and repeat it for all
triples, including extra and biarch triples. The only change
in the gcc-config code itself is adding the call to multilib scan.
Convert the gentoo_linux_gcc_multi_version_tree test input to multilib
x86_64+32+x32 install, and add appropriate tests to linux-header-search
and linux-ld.
Differential Revision: https://reviews.llvm.org/D26887
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289436 91177308-0d34-0410-b5e6-96231b3b80d8
Support using gcc-config to determine the correct GCC toolchain location
on Gentoo. In order to do that, attempt to read gcc-config configuration
form [[sysroot]]/etc/env.d/gcc, if no custom toolchain location is
provided.
Differential Revision: https://reviews.llvm.org/D25661
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285074 91177308-0d34-0410-b5e6-96231b3b80d8
This will be needed for the next commit that allows to switch the default
C++ library which would otherwise make these tests fail.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260661 91177308-0d34-0410-b5e6-96231b3b80d8
Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9
layout for sparc (32bit), sparc (32bit) with lib64 multilib, and
sparc64.
The test cases added here also cover r239047, which fixed the linker
paths.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239154 91177308-0d34-0410-b5e6-96231b3b80d8
Without this patch, this test was accidentally testing that
CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING
were set to a particular set of values.
The test was also getting pretty hairy since it was attempting to craft
a regular expression that covered "all" possible combinations of
settings for these configure-time constants.
Clean it up by directly capturing the resource directory in a FileCheck
variable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227310 91177308-0d34-0410-b5e6-96231b3b80d8
For some regression tests the path to the right toolchain is specified using the -sysroot switch. However, if clang was configured with a custom gcc toolchain (either by using GCC_INSTALL_PREFIX in cmake or the equivalent configure command), the path to the custom gcc toolchain path takes precedence to the one specified by sysroot. This causes several regression tests to fail as they will be using an unexpected path. This patch fixes this issue by adding --gcc-toolchain='' to all tests that rely on that. The empty string causes the driver to pick the path from sysroot instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225182 91177308-0d34-0410-b5e6-96231b3b80d8
modern Debian-based distributions) due to on-going multiarch madness.
It appears that when the multiarch heeader search support went into the
clang driver, it went in in a quite bad state. The order of includes
completely failed to match the order exhibited by GCC, and in a specific
case -- when the GCC triple and the multiarch triple don't match as with
i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find
the libstdc++ target-specific header files.
I assume that folks who have been using Clang on Ubuntu 32-bit systems
have been applying weird patches to hack around this. I can't imagine
how else it could have worked. This was originally reported by a 64-bit
operating system user who had a 32-bit crosscompiler installed. We tried
to use that rather than the bi-arch support of the 64-bit compiler, but
failed due to the triple differences.
I've corrected all the wrong orderings in the existing tests and added
a specific test for the multiarch triple strings that are different in
a significant way. This should significantly improve the usability of
Clang when checked out vanilla from upstream onto Ubuntu machines with
an i686 GCC installation for whatever reason.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216531 91177308-0d34-0410-b5e6-96231b3b80d8
There was already partial support for multi-arch on powerpc64le,
but the MultiarchIncludeDirs setting was missing. This patch
adds the appropriate definition, and also extends the
linux-header-search.cpp test case to verify an Ubuntu 14.04
powerpc64le tree.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211359 91177308-0d34-0410-b5e6-96231b3b80d8
iterating over different library path suffixes and different library versions.
To find the most appropriate library for the given command line flags we
iterate over a set of disk paths. Before probe each path the already
detected set of multilibs are cleared. If the set of paths contains
existing paths which do not satisfy command line flags or do not contain
necessary libraries and object files at all we might lose found multilibs.
The patch updates variables which hold detected multilibs if we really find
a new multilib matches command line flags.
The patch reviewed by Jon Roelofs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208523 91177308-0d34-0410-b5e6-96231b3b80d8
Now instead of just looking in the system root for it, we also look
relative to the clang binary's directory. This should "just work" in
almost all cases. I've added test cases accordingly.
This is probably *very* worthwhile to backport to the 3.4 branch so that
folks can check it out, build it, and use that as their host compiler
going forward.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199632 91177308-0d34-0410-b5e6-96231b3b80d8
which add another wrinkle to the installation of the libstdc++ headers.
Add at least some basic testing of the weirdnesses of Gentoo's layout.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189212 91177308-0d34-0410-b5e6-96231b3b80d8
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165545 91177308-0d34-0410-b5e6-96231b3b80d8
--- log message follows this test ---
[tests] Fixup some tests to work in "CLANG_IS_PRODUCTION" mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154342 91177308-0d34-0410-b5e6-96231b3b80d8
Debian multiarch libraries, this should in theory add support for those
platform's header search rules. I don't have a system to check this
with, so review appreciated. I've added the corresponding tests
referring to the debian multiarch tree.
We are starting to have a relatively completely tested Linux platform
for header search and library search, with several interesting
peculiarities. We should point people at the debian_multiarch_tree when
suggesting new tests. Folks with Debian systems that can check this for
correctness, it would be much appreciated. The missing chunks I know of
are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and
64-bit variants of platforms, and the MIPS and ARM Debian toolchains.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151484 91177308-0d34-0410-b5e6-96231b3b80d8
version of Ubuntu. It has a very broken multiarch configuration, and so
we need special logic to handle it correctly. Fixing and testing this
uncovered a few other trivial issues with the logic that are fixed as
well.
I added tests to cover this as it is hard to notice if you install
recent versions of the OS.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144165 91177308-0d34-0410-b5e6-96231b3b80d8
Karl-Johan Karlsson