[PATCH] D138692: [clang] [MinGW] Improve/extend the gcc/sysroot detection logic

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo created this revision.
mstorsjo added reviewers: rnk, mati865, alvinhochun, tstellar.
Herald added a subscriber: pengfei.
Herald added a project: All.
mstorsjo requested review of this revision.
Herald added a subscriber: MaskRay.
Herald added a project: clang.

There are three functions that try to detect the right implicit
sysroot and libgcc directory setup to use

- One which looks for mingw sysroots located in <clangbin>/../<sysrootname>
- One which looks for a mingw-targeting gcc executables in the PATH
- One which looks in the <gccroot>/lib/gcc directory to find the right one to use, and the right specific triple used for arch specific directories in the gcc/libstdc++ install

These have mostly tried to look for executables named
"<arch>-w64-mingw32-gcc" or "mingw32-gcc" or subdirectories
named "<arch>-w64-mingw32" or "mingw32".

In the case of findClangRelativeSysroot, it also has looked
for directories with the name of the actual triple. This
was added in deff7536278d355977171726124f83aa4bb95419,
with the intent of looking for a directory matching exactly
the user provided literal triple - however the triple here
is the normalized one, not the one provided by the user on
the command line.

Improve and unify this logic somewhat:

- Always first look for things based on the literal triple provided by the user.
- Secondly look for things based on the normalized triple (which usually ends up as e.g. x86_64-w64-windows-gnu), accessed via the Triple which is passed to the constructor
- Then look for the common triple form <arch>-w64-mingw32

The literal triple provided by the user is available via
Driver::getTargetTriple(), but computeTargetTriple() may
change e.g. the architecture of it, so we need to
reapply the effective architecture on the literal triple
spelling from Driver::getTargetTriple().

Do this consistently for all of findGcc, findClangRelativeSysroot
and findGccLibDir (while keeping the existing plain "mingw32"
cases in findGcc and findGccLibDir too).

Fedora 37 started shipping mingw sysroots targeting UCRT,
in addition to the traditional msvcrt.dll, and these use
triples in the form <arch>-w64-mingw32ucrt - see
https://fedoraproject.org/wiki/Changes/F37MingwUCRT.

Thus, in addition to the existing default tested triples,
try looking for triples in the form <arch>-w64-mingw32ucrt,
to automatically find the UCRT sysroots on Fedora 37.
By explicitly setting a specific target on the Clang command
line, the user can be more explicit with which flavour is
to be preferred.

This should fix the main issue in
https://github.com/llvm/llvm-project/issues/59001.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138692

Files:
  clang/lib/Driver/ToolChains/MinGW.cpp
  clang/lib/Driver/ToolChains/MinGW.h
  clang/test/Driver/Inputs/mingw_fedora_tree/usr/lib/gcc/x86_64-w64-mingw32ucrt/12.2.1/include-fixed/.keep
  clang/test/Driver/Inputs/mingw_fedora_tree/usr/x86_64-w64-mingw32ucrt/sys-root/mingw/include/.keep
  clang/test/Driver/Inputs/mingw_fedora_tree/usr/x86_64-w64-mingw32ucrt/sys-root/mingw/include/c++/backward/.keep
  clang/test/Driver/Inputs/mingw_fedora_tree/usr/x86_64-w64-mingw32ucrt/sys-root/mingw/include/c++/x86_64-w64-mingw32ucrt/.keep
  clang/test/Driver/mingw-sysroot.cpp
  clang/test/Driver/mingw.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D138692.477877.patch
Type: text/x-patch
Size: 9248 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20221125/00c1ed47/attachment-0001.bin>