Any news on this?

Right, that looks better indeed :)

I don't have this issue with make check-all in clang/. Just to make sure: are the .keep files of the patch getting created? Otherwise the i386-gnu/ directories will not get created and then it's not surprising that clang doesn't add them to the research paths.

I have updated the patch according to the comment.

I have added static and shared library tests

(there still needs to be work on the test part)

I'll update the diff according to the comments.

Here is the test for realpath extension fixed.

(I can't commit this myself)

I have added a few checks (the ld.so dynamic linker specification, the ../lib32 paths, and /usr/lib/i386-gnu)

I believe this version handles all the comments.
I could run this with check-all on a linux-amd64 box.

In general when structuring your code, the performance penalty for other targets when the conditions that can be easily tested are not met should pretty much be close to nonexistent. I would suggest keeping that in mind when submitting revisions.

Doesn't APPLE imply MACH anyway outside of targets that are way out of scope of libc++?

I have dropped the endif comment as requested.

This includes version finding the gcc Hurd triplet (i[3456]-gnu) in the Gcc detector.

So we are back with this.

In this version, the Driver introduces the "-hurd-" part

(I can't commit this myself)

i386-pc-hurd-gnu is fine as is, however, it seems that you want to be able to use i386-pc-gnu from Clang, if I understand correctly.

Or perhaps at least keep a Triplet::isOSHurd() which does the hurd-specific triplet parsing, instead of adding a function to clang to be used wherever we want to check for that?

I'm not sure to understand: do you mean to drop this patch entirely, so that llvm considers i386-pc-gnu as just a GNU-ish platform, and then Driver::getToolChain should special-case the Triple::UnknownOS and parse Triple::getTriple itself to call the Hurd code instead of the default toolchains::Generic_GCC case?

(as expected, I could run make check-all fine on an x86_64 linux host)

Perhaps we could go this way with additional code in cmake/config-ix.cmake, to get "hurd-gnu" as soon as possible just after detection and keep everything else inside llvm straight with llvm conventions?

Ah, right, sorry, done so now.

Well, that's what I did the in the latest version?

For sure I consider that not breaking anything on other archs is a must :)

In D54378#1294256, @rengolin wrote:

In D54378#1294253, @sthibaul wrote:

Well, it definitely is for GNU/Hurd, now that very basic software pieces such as librsvg start _depending_ on rust, which is available only through llvm.

That was an old Hurd joke (that it would never be used by anyone), thus the smiley face. Jokes don't work well on the Internet, sorry.

I'm getting an immense amount of errors, did you run make check-all on this patch?

if people forget the OS part, for example, write "target-gnu" instead of "target-linux-gnu".

not supporting Hurd at all (which is not that big of a problem, I get it :).

I commented one of them, and will fix the rest.

I understand your concerns, but that's really not something that we can change at this point, there is far too much software which has written i386-pc-gnu in their source code for us to change all that.

The Hurd::Hurd constructor would actually need to do the same gcc inclusion path detection as on Linux, but let's leave this aside for now, this commit is enough for a build without libc++.

(I can not commit this myself)

The GNU/Hurd triple is target-gnu, simply.

So that'd be it? I don't know if libcxx supports more than free/net/open bsd and apple ?

(I cannot commit this myself)

Here it is

(I can not commit this myself)

Note: I added the realpath call for all OSes hitting this part of the code, in case the behavior would be the same on some other OSes. We could instead just call realpath(exe_path, NULL); only in the __GNU__ case (i.e. GNU/Hurd) instead if it is preferred.