Hi, thanks for tackling this issue. I think it's unfortunate Wine doesn't allow being built with LTO still, especially when some of the reason is that Wine's code is simply wrong—and it happens to work without LTO, but it's actually bad/undefined behavior.
But I think it's overcomplicated, especially the tool/build changes you've done. Why not just do something similar to my MR !4908? Why use environment variables for NM/AR/RANLIB? Autodetection could be done, but in the case of my MR, gcc prefixed versions are a superset (feature-wise) of the normal ar/nm/ranlib so using them unconditionally is totally fine, if they're available. Similar things are done for LLVM, I don't get why not for GCC.
Sadly I haven't got any comments on it, but I do think it's much simpler and has 0 configuration issues.
With respect to the other "skip source file" changes: I personally would prefer to isolate the reason those sources fail and fix that instead. With some asm functions it's harder (because of a GCC bug), but in many cases it's just a matter of applying the `used` attribute where applicable. Some functions are only called from asm code, so marking them as `used` is the right thing to do. Currently IMO it's actually undefined behavior since they're not exported, so we shouldn't rely on them not being cleaned up if unused.