[cfe-commits] r164177 - in /cfe/trunk: lib/Driver/ test/Driver/ test/Driver/Inputs/freescale_ppc_tree/ test/Driver/Inputs/freescale_ppc_tree/lib/ test/Driver/Inputs/freescale_ppc_tree/usr/ test/Driver/Inputs/freescale_ppc_tree/usr/lib/ test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/ test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/4.6.2/

[Chandler Carruth via cfe-commits]

On Thu, Feb 9, 2017 at 2:46 PM Tobias von Koch <tobias.von.koch at gmail.com>
wrote:

> On Wed, Feb 8, 2017 at 7:21 PM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>
> +    // The Freescale PPC SDK has the gcc libraries in
> +    // <sysroot>/usr/lib/<triple>/x.y.z so have a look there as well.
> +    "/" + CandidateTriple.str(),
>
>
> So, this is really bad it turns out.
>
> We use this directory to walk every installed GCC version. But because
> this is just a normal lib directory on many systems (ever Debian and Ubuntu
> system for example) this goes very badly. It goes even more badly because
> of the (questionable) design of LLVM's directory iterator:
>
>
> Wow, this is pretty bad, but it really sounds like the iterator should be
> fixed rather than trying to hack around it.
>

I mean, we should.

But even then, walking the entire directory seems bad too... See below.


> Doesn't this happen for the other directories as well (which, admittedly,
> will have less entries)?
>

The *only* entries in the other directories are the actual installed GCC
toolchains though, so walking them makes a lot of sense. The tricky thing
is that this isn't a gcc-specific directory.

I suspect the fix should be to not use this base path as part of the walk
to discover GCC toolchains, and instead to hard code the specific toolchain
patterns on this specific platform.

Or we could do the walk, but only when actually on the NXP/Freescale Power
platform where this is necessary to find GCC installations.

Both of those would seem reasonable. Fixing the directory iterator would be
icing on the cake IMO. =D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170209/c0bf0f36/attachment.html>