On Mon Mar 3 21:32:42 2025 +0000, Gabriel Ivăncescu wrote:
Thanks. I'm still not a fan of the environment variables like `WINE_AR`, is there a reason you aren't just unconditionally using `gcc-ar` if available? It is a superset of `ar` anyway. I think you should split the last patch, yeah. In particular, you disable too many files. For example, why are you disabling `d3d9/device.c` from having LTO? A lot of those files can also be "fixed" by fixing just the actual cause of the issue (for example, marking functions with `used` attribute) instead of disabling LTO completely. The only problematic ones are those **exporting** asm functions. I think it would be great for Wine to have LTO. But well, it's not really up to me. Alexandre hasn't really commented on any of the LTO MRs. :/
I don't want to hardcode toolchain-based tool names because Wine is buildable with Clang or GCC and if both are present in environment this may lead to unforeseen consequences. Both winebuild and winegcc have similar tool/binary lookup functions so I'd write unified implementation.
Last patch is merely quirk so it may disable LTO for more sources than is actually required.