Check whether the libc++ library is available when using -stdlib=libc++,
and also adjust the check for whether to link with -lgcc_s.1.
Patch by Ted Kremenek and Daniel Dunbar.
llvm-svn: 141374
this saga. Teach the driver to detect a GCC installed along side Clang
using the existing InstalledDir support in the Clang driver. This makes
a lot of Clang's behavior more automatic when it is installed along side
GCC.
Also include the first test cases (more to come, honest) which test both
the install directory behavior, and the version sorting behavior to show
that we're actually searching for the best candidate GCC installation
now.
llvm-svn: 141145
There should be a better solution to this; Michael and I are continuing
to discuss exactly what it should be. The one solution I'm very
uncomfortable with is making the FileCheck tests use a regex for each
path separator.
llvm-svn: 141126
installations, support them when installed directly under the system
root ('/lib/gcc/...' essentially).
With this, Clang can correctly detect and use a cross-compiling GCC
installation within a system root and use it.
Again, test cases will be coming in later commits, as I'm going to write
a few test cases that exercise nearly all of this logic.
llvm-svn: 141121
two fundamental changes, as they ended up being interrelated.
The first is to walk from the root down through the filesystem so that
we prune subtrees which do not exist early. This greatly reduces the
filesystem traffic of this routine. We store the "best" GCC version we
encounter, and look at all of the GCC installations available.
Also, we look through GCC versions by scanning the directory rather than
using a hard-coded list of versions. This has several benefits. It makes
it much more efficient to locate a GCC installation even in the presence
of a large number of different options by simply reading the directory
once. It also future-proofs us as new GCC versions are released and
installed. We no longer have a hard coded list of version numbers, and
won't need to manually updated it. We can still filter out known-bad
versions as needed. Currently I've left in filtering for all GCC
installations prior to 4.1.1, as that was the first one supported
previously.
llvm-svn: 141120
GCC installation search that requires fewer filesystem operations.
Planning to implement that next as the current approcah while thorough
(and so far looks correct) does a very unfortunate number of filesystem
operations.
I'm motivated to fix this in no small part because I would like to
support a much larger space of triples and GCC versions, which would
explode the current algorithm.
llvm-svn: 141073
find the newest GCC available, among other goodness. It makes the entire
system much less prone to error from prefixes and/or system roots
pruning early the set of triples and GCC versions available.
Also, improve some comments and simplify the forms of some of the loops.
This causes the driver to stat directories more often than is strictly
necessary, but the alternatives which I looked at that still
accomplished this goal needed quite a bit more code and were likely not
much faster.
Test cases for this, now that our behavior here is significantly more
principled and predictable, should come tomorrow as I walk back through
VMs looking for edge cases that are missed after this.
llvm-svn: 141072
significantly cleaner (IMO) and more principled. We now walk down each
layer of the directory hierarchy searching for the GCC install. This
change does in fact introduce a significant behavior change in theory,
although in practice I don't know of any distro that will be impacted by
it negatively, and Debian may (untested) get slightly better through it.
Specifically, the logic now looks exhaustively for patterns such as:
/usr/lib/<triple>/gcc/<triple>
Previously, this would only be selected if there was *also*
a '/usr/lib/gcc/<triple>' directory, or if '<triple>' were the excat
DefaultHostTriple in the driver.
There is a 4-deep nested loop here, but it doesn't do terribly many
filesystem operations, as we skip at each layer of that layer's
directory doesn't exist.
There remains a significant FIXME in this logic: it would be much better
to first build up a set of candidate components for each of the four
layers with a bottom-up pruning such as this, but then select the final
installation using a top-down algorithm in order to find the newest GCC
installation available, regardless of which particular path leads to it.
llvm-svn: 141071
installations. This first selects a set of prefixes and a set of
compatible triples for the current architecture. Once selected, we drive
the search with a single piece of code.
This code isn't particularly efficient as it stands, but its only
executed once. I'm hoping as I clean up the users of this information,
it will also slowly become both cleaner and more efficient.
This also changes the behavior slightly. Previously, we had an ad-hoc
list of prefixes and triples, and we only looked for some triples
beneath specific prefixes and vice versa. This has led to lots of
one-off patches to support triple X, or support lib dir Y. Even without
going to a fully universal driver, we can do better here. This patch
makes us always look first in either 'lib32' or 'lib64' on 32- or 64-bit
hosts (resp.). However, we *always* look in 'lib'.
Currently I have one lingering problem with this strategy. We might find
a newer or better GCC version under a different (but equally compatible)
triple. Fundamentally, this loop needs to be fused with the one below.
That's my next patch.
llvm-svn: 141056
is designed to allow the detection to record more rich information about
the installation than just a single path.
Mostly, the functionality remains the same. This is primarily
a factoring change. However, the new factoring immediately fixes one
issue where on ubuntu we didn't walk up enough layers to reach the
parent lib path. I'll have a test tree for that once I finish making the
Ubuntu tree work reasonably.
llvm-svn: 141011
enabled for debian hosts, which is quite odd. I think all restriction on
when Clang attempts to use a multilib installation should go away. Clang
is fundamentally a cross compiler. It behaves more like GCC when built
as a cross compiler, and so it should just use multilib installs when
they are present on the system. However, there is a very specific
exemption for Exherbo, which I can't test on, so I'm leaving that in
place.
With this, check in a generic test tree for multilib on a 32-bit host.
This stubs out many directories that most distributions don't use but
that uptsream GCC supports. This is intended to be an agnostic test that
the driver behaves properly compared with the GCC driver it aims for
compatibility with.
Also, fix a bug in the driver that this testing exposed (see!) where it
was incorrectly testing the target architecture rather than the host
architecture.
If anyone is having trouble with the tree-structure stubs I'm creating
to test this, let me know and I can revisit the design. I chose this
over (for example) a tar-ball in order to make tests run faster at the
small, hopefully amortized VCS cost.
llvm-svn: 140999
This requires fixing a latent bug -- if we used the default host triple
instead of an autodetected triple to locate GCC's installation, we
didn't go back and fix the GCC triple. Correct that with a pile of
hacks. This entire routine needs a major refactoring which I'm saving
for a subsequent commit. Essentially, the detection of the GCC triple
should be hoisted into the same routine as we locate the GCC
installation: the first is intrinsically tied to the latter. Then the
routine will just return the triple and base directory.
Also start to bring the rest of the library search path logic under
test, including locating crtbegin.o. Still need to test the multilib and
other behaviors, but there are also bugs in the way of that.
llvm-svn: 140995
This is still very much a WIP, but sysroot was completely broken before
this so we are moving closer to correctness.
The crux of this is that 'ld' (on Linux, the only place I'm touching
here) doesn't apply the sysroot to any flags given to it. Instead, the
driver must translate all the paths it adds to the link step with the
system root. This is easily observed by building a GCC that supports
sysroot, and checking its driver output.
This patch just fixes the non-multilib library search paths. We should
also use this in many other places, but first things first.
This also allows us to make the Linux 'ld' test independent of the host
system. This in turn will allow me to check in test tree configurations
based on various different distro's configuration. Again, WIP.
llvm-svn: 140990
precisely match the pattern and logic used by the GCC driver on Linux as
of a recent SVN checkout.
This happens to follow a *much* more principled approach. There is
a strict hierarchy of paths examined, first with multilib-suffixing,
second without such suffixing. Any and all of these directories which
exist will be added to the library search path when using GCC.
There were many places where Clang followed different paths, omitted
critical entries, and worst of all (in terms of challenges to debugging)
got the entries in a subtly wrong order.
If this breaks Clang on a distro you use, please let me know, and I'll
work with you to figure out what is needed to work on that distro. I've
checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora,
and Gentoo. I'll be testing it on those as well as Debian stable and
unstable and ArchLinux. I may even dig out a Slackware install.
No real regression tests yet, those will follow once I add enough
support for sysroot to simulate various distro layouts in the testsuite.
llvm-svn: 140981
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.
llvm-svn: 140908
This replaces the hack to read UNAME_RELEASE from the environment when
identifying the OS version on Darwin, and it's more flexible. It's also
horribly ugly, but at least this consolidates the ugliness to touch less of
the code so that it will be easier to rip out later.
llvm-svn: 140187
feature akin to the ARC runtime checks. Removes a terrible hack where
IR gen needed to find the declarations of those symbols in the translation
unit.
llvm-svn: 139404
output on darwin so is hard coded there.
As a note this will need a little bit of refactoring in the class
hierarchy to separate it out for different verifiers based on input type.
Fixes rdar://8256258.
llvm-svn: 138343
Outside the driver, they were already treated that way, but the driver was not
giving them the same special treatment as -fapple-kext, e.g., falling back to
llvm-gcc for i386/Darwin kexts. Radar 9868422.
llvm-svn: 137639
Since -mkernel implies -fapple-kext, this just extends the current behavior
for -fapple-kext to apply for -mkernel as well. Radar 9933387.
llvm-svn: 137566
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
llvm-svn: 134453
AFAIK, RHEL5 (and its clones) provides g++44 as the package "gcc44-c++".
By default, g++-4.1.1 is available, though, its libstdc++ would not be suitable to clang++.
llvm-svn: 133156
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
we look in /usr/lib to find crt1.o, and that depends only on where libc
is installed.
This fixes the case of using a different gcc installation in a distro
without multilib.
llvm-svn: 132551
Before this patch we would still link with the system libstdc++. It worked
fine most of the time, but would break if the used headers were a lot newer
than the system libraries.
This patch changes the driver to use the libraries corresponding to the
headers the user selected.
This fixes, for example, using 4.5 headers in a system with gcc 4.1.
llvm-svn: 132497
Preserve the original triple in the NetBSD toolchain when using -m32 or
-m64 and the resulting effective target is different from the triple it
started with. This allows -m32 to use the same assembler/linking in
cross-compiling mode and avoids confusion about passing down target
specific flags in that case like --32.
llvm-svn: 131404
compare it with getDriver().Dir.c_str(), since that is a pointer
comparison, not a "are these strings equal" comparison.
Instead, just compare with getDriver().Dir directly, so both sides will
get promoted to std::string, and the regular std::string comparison
operator applies.
Patch by Dimitry Andric!
llvm-svn: 126791
ToolChain's FilePaths. If clang is installed as a port in /usr/local,
it is *not* supposed to use /usr/local/lib by default, for example.
Additionally, there are no clang-related executables in either
/usr/libexec, or getDriver().Dir + "/../libexec", anymore, so remove
that from the ToolChain's ProgramPaths.
Patch by Dimitry Andric!
llvm-svn: 126760
*) Try to detect as much as possible from the system itself, not the distro.
This should make it easier to port to a new distro and more likely to
work on a unknown one.
*) The distro enum now doesn't include the arch. Just use the existing
host detection support in LLVM.
*) Correctly handle --sysroot.
A small regression is that now clang will pass bitcode file to the linker.
This is necessary for the gold plugin support to work.
It might be better to detect this at configure/cmake time, but doing it in
c++ first is a lot easier.
llvm-svn: 118382
distros listed by running
gcc main.o -o main
g++ main.o -o main
gcc main.o -o main -static
g++ main.o -o main -static
gcc f.o -o f.so -shared
g++ f.o -o f.so -shared
and comparing the ld line with the one created by clang. I also added
-m32/m64 in distros that support it.
While I tested many distros, there will always be more. If you are hit by this
it should be somewhat easy to add your distro. If you are in a hurry, do
revert this, but please inform how to detect you distro and the ld command
lines produced by the above gcc invocations. Most distros have some patches
on gcc :-(
llvm-svn: 118149
the GCC dir. Unfortunately, this breaks -lstdc++ on SnowLeopard, etc. because
the libstdc++ dylib was hiding there. Workaround this by providing the path to
the right -lstdc++.6 (the only version used in recent memory) if we can't see an
obvious -lstdc++, but can find = -lstdc++.6.
llvm-svn: 114146
ToolChain. This fixes a potenial bad cast when running Clang on PPC code, since
the tool chain in effect is not a subclass of the Darwin one, but we were
treating it like it was.
- This introduces some gross code duplication, but the right fix for it is to
just move the Driver to start depending on the targets in libBasic, so I am
not planning on fixing it immediately.
llvm-svn: 111856
was invoked from (which may not be where the executable itself is).
- This allows having e.g., /Developer/usr/bin/clang be a symlink to some other
location, while still making sure the Driver finds 'as', 'ld', etc. relative
to itself.
llvm-svn: 109989
means it isn't really possible to write the test case for this code, but this is
the kind of thing that really requires testing against the installed compiler
anyway.
llvm-svn: 100935
Clang is installed. This is designed to match gcc, and is important when
installed in a non-standard location.
- This is gross, but no worse than ever. It will die when we finally move to
the compiler-rt based toolchain, any day now.
llvm-svn: 100915
to compile a translation unit into the debug info for that file.
- Used by parts of Darwin build process to check compiler flags, etc.
- <rdar://problem/7256886> clang does not emit AT_APPLE_flags
llvm-svn: 91661
- This commit has some messy stuff in it to extend string lifetimes, but that
will go away once we switch to using the enum'd Triple interfaces.
llvm-svn: 72243
- This is really gross, but its the easiest way to match gcc. Once we
are confident in the driver, we can try and push these translations
down into tools.
- No test cases for this yet, it's hard to see the effects of these
translations before the gcc tool argument translation is pulled
over.
- Interaction with "unused argument" warning hasn't been worked out
yet.
- <rdar://problem/6717359> [driver] implement toolchain specific
argument translation.
"It's horrible in here."
llvm-svn: 67683
- Lift ArgList to a base class for InputArgList and DerivedArgList.
- This is not a great decomposition, but it does embed the
translation into the type system, and keep things efficient for
tool chains that don't want to do any translation.
- No intended functionality change.
Eventually I hope to get rid of tool chain specific translation and
have each tool do the right thing, but for now this is the easiest way
to match gcc precisely (which is good for testing).
llvm-svn: 67676
Bob Wilson