Triple naming probably unorthodox
Closed this issue · 4 comments
Little follow up of #76
Hi. I am one of the packagers of the GIMP project and I am personally considering add llvm-mingw support to crossroad with the intention of further use it in our nightly crossbuild, which is actually the only one that doesn't use clang, all the others (native) builds (debian, flatpak, windows and macOS are clang based) 🙂 .
However, after downloading the artifact in the latest release, I noticed that the triple naming couldn't be so reliable. For example, it uses:
x86_64-w64-mingw32-gcc (which I presume that it is using UCRT)
But Fedora uses:
x86_64-w64-mingw32ucrt-gcc
This project seems to be well stablished with a long commit history and good number of contributors, but I'm afraid about relying in this actual naming. I think that would be a good idea following the Fedora naming(?), which was even a bit discussed with the upstream (mingw-w64): https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CAMxuvax0nSO5%2BMRNQG%3DkBiN%3DPPAFbXrzAR-OVgS0kiKoVPeWSw%40mail.gmail.com/
This project seems to be well stablished with a long commit history and good number of contributors,
Relevant context: This project is the original reference example of using the UCRT target in mingw-w64 overall - I implemented the UCRT support in mingw-w64, and tested it out within llvm-mingw, while other toolchains picked it up later.
I think that would be a good idea following the Fedora naming(?)
Note that the naming used in Fedora appeared 4 years after this toolchain already had established the use of the plain mingw32 triples for this target here.
And as mentioned in the mail chain you linked, within msys2, the plain triple <arch>-w64-mingw32 is used for UCRT targets, just like llvm-mingw.
but I'm afraid about relying in this actual naming.
I wonder what you're afraid of here? If you switch from one toolchain supplier to another, you might need to change the triple prefix you use for invoking the toolchain - that's true, but I kind of fail to see which long term commitment that might be problematic?
(Back in the day, before the mingw-w64 fork, the common triple for mingw.org based toolchains used to be e.g. i586-pc-mingw32msvc, while it nowadays mostly is e.g. i686-w64-mingw32. Each toolchain provider usually can set up a different one based on their preferences anyway.)
Admittedly, it looks like it could be convenient to have the triple disambiguate whether the toolchain uses msvcrt or UCRT - but if we go down that path, it could also be similarly good to know if the toolchain uses libstdc++ or libc++. And we probably can't start encoding all these aspects into the triple.
In short - I don't quite see what the big issue is. I agree that Fedora's use of the triples is reasonable - but I don't, yet at least, feel an urge to change llvm-mingw over to use that naming style. While it would seem convenient and consistent to you, as a new user, it would also be disruptive to existing established users of llvm-mingw.
Both forms are fine and there is no single "right" form in mingw ecosystem. CRT module is one of choices that vendor does when building the toolchain and it may or may not choose to expose that as a part of triple.
Relevant context: This project is the original reference example of using the UCRT target in mingw-w64 overall
I didn't know. Good work by the way.
but if we go down that path, it could also be similarly good to know if the toolchain uses libstdc++ or libc++. And we probably can't start encoding all these aspects into the triple.
CRT module is one of choices that vendor does when building the toolchain and it may or may not choose to expose that as a part of triple.
Makes sense, closing and thanks 🤝.
Admittedly, it looks like it could be convenient to have the triple disambiguate whether the toolchain uses msvcrt or UCRT - but if we go down that path, it could also be similarly good to know if the toolchain uses libstdc++ or libc++. And we probably can't start encoding all these aspects into the triple.
I forgot one aspect here as well; the kind of exception handling mechanism - which can be either SJLJ, DWARF or SEH - that also affects interoperability of object files and even DLLs. And there's no common practice of encoding this aspect into the triple.