r193601 - Teach the driver to not try to use 'lib32' multilib spellings on ARM

[Chandler Carruth]

On Tue, Oct 29, 2013 at 9:14 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > Do these redundant search paths break fedora in any way?
>
> They don't break it. They *are* redundant and they do make it harder
> to compare clang's behavior with gcc's.
>

I should have mentioned it in my commit log (thought about it, an didn't
write it down), but I was aware of the redundancies. These are not the only
places where we search a superset of the paths that GCC searches, we do it
in quite a few places.

The GCC toolchains you're comparing to, as far as I can tell, are disabling
specific behaviors that remove entries from the search paths. Previously,
when building the initial version of this code, I built vanilla GCC from a
clean checkout, enabling essentially all of the features. I did this for
both cross and native compilers. Then I created every directory I could
come up with in every permutation, and observed how GCC searched the paths.

This resulted in the code we have today. Now, on some systems, GCC tends to
skip steps in this search, etc. This is typically because of compile time
'configure' switches that we can't necessarily detect. However, searching
all of the paths when they exist has proven consistently to be a viable
alternative. Clang has been doing it for a long time, and the number of
complaints are very small. So I don't think this was the wrong technical
design of the system.

It also isolates us from problems when Clang is installed on a new distro,
or with a new GCC, which was a primary goal of the original design.

The cost is, as you cite, a lack of 1:1 correspondence to the GCC search
paths. However, I think there are very few ways of achieving that. The only
one that springs to mind would be to invoke GCC itself to discover its
search paths, but that has been met with strong resistance in the past. Or
we could hard code different variations at build time, and build a
different clang for each spec file used to build a GCC. I don't see many
other alternatives.


>
> If we don't care about printing paths as gcc does, why are we even
> adding things like "lib/.." and printing redundant search path?
>

So that when it *is* relevant (such as when multilib != 'lib', or when
symlinks are in play) we can use the same logic and everything just works.
GCC makes the same tradeoff here AFAICT.


Note that all of these search paths are also somewhat intrinsically broken
-- they search /usr/lib, which won't have the right architecture libraries.
I'm not aware of any *really* solid way of targeting a platform without
using a sysroot. Clang's support for using a sysroot and either a GCC
installation inside the sysroot or an installation outside the sysroot is,
to the best of my knowledge, really solid. We use that every day.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131029/a0b8cdda/attachment.html>