yes, please, Samuel Thibault <samuel.thibault@ens-lyon.org> will be fine, thanks

This is still not showing up on https://github.com/llvm/llvm-project/blob/main/llvm/lib/WindowsManifest/CMakeLists.txt , is there some more steps needed from my side?

I try to make Hurd.cpp close to Linux.cpp in general, yes.

No, for now it only supports i686.
This part is actually already being tested by hurd.cpp, /usr/include/i386-gnu wouldn't be getting included otherwise.

Rebase on refreshed D101331

Rebase on newer D101317

Fix triplet

Rather use i686-gnu triplet

@MaskRay could you review this one as well? Most others are based on it.

Retrigger buildable with the dep

Fix clang-tidy warning

Retrigger buildable

Retrigger buildable

FI, I don't have commit access.

Move all tests to hurd.cpp

Fix GCCInstallation.isValid use in Generic_GCC::addLibStdCxxIncludePaths
Fix test further

Fix test

Oh.
It was committed already as c298e5a022928b59941d74680a41fc9c76038b2a ("[Gnu toolchain] Move GCC multilib/multiarch paths support from Linux to Gnu") but apparently with the wrong Differential Revision (D73845 instead of D74282).
Now closing.

@MaskRay @phosek : can we have a look at this then?

@MaskRay : Samuel Thibault <samuel.thibault@ens-lyon.org>

Thanks! I don't have commit access, could somebody commit this for me?

ping @phosek ?

In D73845#1971282, @MaskRay wrote:

Moving functions from Linux.cpp to Gnu.cpp is definitely appropriate. Have you made any adjustment?

Hello, any news on this?

I however didn't find how to specify in phabricator a dependency between the two diffs, is that supported in phabricator?

I feel like in this specific case it may be worth splitting this into two patches:

Alright, doing so.

I feel like in this specific case it may be worth splitting this into two patches:

Right, here is an updated patch

There is no behavior change, I checked for no regression on GNU/Linux with ninja check-all.

Let me know if you need this committed.

I am actually getting many failures with ninja check-all on my build box:

(I don't see anything looking like what you have, so can't investigate)

Which checksuite are you running? I had been using ninja check-all, and I do indeed get unexpected failures, but exactly the same set of failures as when building against master.

[Gnu toolchain]
maybe this can be removed in the title?

I have updated the patch to the latest git and re-ran checks. Could somebody have a look at it please?

Not sure what NFCI means, but for Linux the behavior should just not change at all, and the testsuite indeed behaved exactly the same on Linux indeed.

Here it is updated to use gnu_hurd, please commit indeed

gnu_hurd can work as well indeed

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 addresses 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?