the detected GCC installation. This allows us to expose another aspect
of what we detected: the GCC version. This will be used shortly.
llvm-svn: 143871
directories. This way we stop at the first multiarch directory found on
the system. This achieves the real intended result of pruning
non-existent directories.
llvm-svn: 143866
a better way. The more I think about it the more worried I am that this
hammer is simply too large. We should only be reaching out to the
filesystem when doing interesting "detection" things, not gratuitously.
Original commit message:
Start pruning down the set of flags passed to CC1 for header search.
This cleans up the CC1 invocations, and reduces the overhead there.
We're still hammering the filesystem looking for the C++ standard
libraries though.
The only reservation I have about this policy is the case of virtualized
files inside of CC1, but it's not clear what the best way to solve that
is. The Driver consistently queries the actual filesystem to make its
decisions. Changing that would be a very large undertaking. It might be
worthwhile, but it's not an immediate goal.
llvm-svn: 143865
This cleans up the CC1 invocations, and reduces the overhead there.
We're still hammering the filesystem looking for the C++ standard
libraries though.
The only reservation I have about this policy is the case of virtualized
files inside of CC1, but it's not clear what the best way to solve that
is. The Driver consistently queries the actual filesystem to make its
decisions. Changing that would be a very large undertaking. It might be
worthwhile, but it's not an immediate goal.
llvm-svn: 143864
edge cases and have better behavior. Specifically, we should actually
prefer the general '4.6' version string over the '4.6.1' string, as
'4.6.2' should be able to replace it without breaking rpaths or any
other place that these paths have been embedded. Debian-based
distributions are already using a path structure with symlinks to
achieve in-place upgrades for patch versions. Now our parsing reflects
this and we select the shorter paths instead of the longer paths.
A separate issue was that we would not parse a leading patch version
number even in the presence of a suffix. The above change makes this
more problematic as it would cause a suffix being added to make us treat
the entire thing as patch-version-agnostic, which it isn't. This changes
the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that
the latter has *some* patch number information. Currently, we always
bias toward the shorter and more canonical version strings. If it
becomes important we can add more Debian like rules to produce sequences
such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5',
but I'm very doubtful this will ever matter or be desirable.
I've made the tests for this logic a bit more interesting, and added
some specific tests for logic that is now different.
llvm-svn: 143841
variable to begin with... As I'm planning to add include root
information to this object, this would have caused confusion. It didn't
even *actually* hold the include root by the time we were done with it.
llvm-svn: 143840
toolchain instead of merely using it in the constructor. This will allow
us to query it when building include paths as well as the file search
paths built in the constructor. I've lifted as little of it as I could
into the header file.
Eventually this will likely sink down into some of the Generic
toolchains and be used on more platforms, but I'm starting on Linux so
I can work out all the APIs needed there, where it is easiest to test
and we have the most pressing need.
llvm-svn: 143838
headers. As llvm-gcc is dead, and I have no idea if this ever really
worked, I think it's time for it to go. More importantly, it makes it
harder to generalize the include search logic. If someone really wants
these to work, they can set the CPLUS_INCLUDE_PATH environment variable.
llvm-svn: 143836
the first (and diff-noisiest) step to making Linux header searching
tremendously more principled and less brittle. Note that this step
should have essentially no functional impact. We still search the exact
same set of paths in the exact same order. The only change here is where
the code implementing such a search lives.
This has one obvious negative impact -- we now pass a ludicrous number
of flags to the CC1 layer. That should go away as I re-base this logic
on the logic to detect a GCC installation. I want to do this in two
phases so the bots can tell me if this step alone breaks something, and
so that the diffs of the refactoring make more sense.
llvm-svn: 143822
actually manage the builtin header file includes as well as the system
ones.
This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.
Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.
Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.
llvm-svn: 143801
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.
There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.
Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.
llvm-svn: 143798
Windows. There are still FIXMEs and lots of problems with this code.
Some of them will be addressed shortly by my follow-up patches, but most
are going to wait until we isolate this code and can fix it properly.
This version should be no worse than what we had before.
llvm-svn: 143752
I don't have any Debian system with one of these currently, and it seems
unlikely for one to show up suddenly. We can add more patterns here if
they become necessary.
llvm-svn: 143346
library search logic to "properly" handle multiarch installations. I've
tested this on both Debian unstable and the latest Ubuntu which both use
this setup, and this appears to work largely the same way as GCC does.
It isn't exactly the same, but it is close enough and more principled in
its behavior where it differs. This should resolve any failures to find
'crt1.o' etc on Debian-based Linux distributions. If folks find more
cases where we fail, please file bugs and CC me.
Test cases for all of the debian silliness are waiting both to simplify
the process of merging these down into the 3.0 release, and because
they're so crazy I haven't yet been able to really produce a fake tree
that represents what we need to test for. I'll eventually add them
though.
llvm-svn: 143344
'libdir' mean the actual library directory, not the GCC subdirectory of
the library directory. That was just a confusing pattern. Instead,
supply proper GCC subdirectories when scanning for various triple-based
subdirectories with a GCC installation in them. This also makes it much
more obvious how multiarch installations, which have a triple-based
prefix as well as suffix work.
Also clean up our handling of these triple-prefixed trees by using them
in both a multiarch pattern and a non-multiarch pattern whenever they
exist.
Note that this *does not* match what GCC does on Debian, the only truly
multiarch installation I've been able to get installed and test on. GCC
appears to have a bug, and ends up searching paths like
'/lib/../../lib32' which makes no sense what-so-ever. Instead, I've
tried to encode the rational logic that seems clearly intended by GCC's
pattern. GCC ends up with patterns like:
/lib/../../lib32
/usr/lib/../../lib32
/usr/lib/x86_64-linux-gnu/../..lib32
Only the last one makes any sense having a '/../..' in it, so in Clang,
that's the only one which gets a '/../..' in it.
I *think* this will fix Debian multiarch links. I'm committing without
baking this logic into our test suite so I can test on a few different
systems. If all goes well (and no one screams) I'll check in some more
comprehensive tests for multiarch behavior tomorrow.
llvm-svn: 142133
There are now separate Triple::MacOSX and Triple::IOS values for the OS
so comparing against Triple::Darwin will fail to match those. Note that
I changed the expected output for the Driver/rewrite-objc.m test, which had
previously not been passing Darwin-specific options with the macosx triple.
llvm-svn: 141944
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
