mstorsjo
commented
5 days ago Thanks for checking in!
See https://github.com/mstorsjo/llvm-mingw/issues/253 for more discussion around the use of config files. The issues I ran into, which I mentioned in the revert, https://github.com/mstorsjo/llvm-mingw/commit/e0964ce24c086bb9f7de0916157f9177e85049d6, have been fixed.
-
https://gitlab.winehq.org/wine/wine/-/commit/0872e3c1ff242dc17f18749efb1e285c1155399b fixes the issue in wine, by not passing
--no-default-configfor the cases when Wine needs to find the libgcc/compiler-rt builtins files. -
The issue with testing compiler-rt was fixed in https://github.com/llvm/llvm-project/pull/113491, and the fix is being backported to 19.x in https://github.com/llvm/llvm-project/pull/114229.
So the config files themselves work fine overall, but there seems to be a bit of occurrance that some projects build with --no-default-config (to combat cases where afaik Gentoo have a global default that sets options that aren't really suitable for some cases of cross compilation and/or testing).
Note that while the config files are neat for many things, the mingw32uwp target (which admittedly sees very little use) doesn't quite work neatly with config files, at least not without changing what triples it uses. Also, for this configuration, see https://github.com/mstorsjo/llvm-mingw/blob/master/wrappers/clang-target-wrapper.sh#L82-L83 - we intentionally pass these default linker options after the user specified ones, rather than before, to make sure the user specified libs to link have precedence. I'm not sure if there's a neat way to do that with config files...
If there are no more surprises, the next point release of llvm-mingw will use the config files, and once that's out, I guess we'll get more widespread testing of it, and see if people stumble on other issues with it.
I was just doing my usual post-llvm-update update of my cross-compiler wrappers (msys2/MINGW-packages#8762) (which are basically ripped off from yours), which includes looking to see if you made any relevant changes to the wrappers here. I saw a somewhat confusing commit history, where you switched to using cfg files, tweaked them, then reverted all of that due to several issues, and then seemingly reapplied the commits without change. I decided for this go-around to use the version of the wrappers at the revert (which was just a comment update different from what I had before), but I wanted to check in to see how the issues referenced in the revert were addressed here before I consider also switching to cfg files.