<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 29, 2013 at 9:14 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank" class="cremed">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Do these redundant search paths break fedora in any way?<br>
<br>
</div>They don't break it. They *are* redundant and they do make it harder<br>
to compare clang's behavior with gcc's.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If we don't care about printing paths as gcc does, why are we even<br>
adding things like "lib/.." and printing redundant search path?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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.</div>
</div></div></div>