Supporting alternative toolchains on Windows

[Magnus Ihse Bursie]

On 2022-03-11 20:02, Julian Waters wrote:
> I understand the concerns, seems like I grossly underestimated the 
> complexity such a task would entail. Though I would say the following 
> can only really be known if it's already been implemented:
>
>         Most likely there will be strange bugs with anything that 
> requires OS interaction (like dll loading and whatsnot)
>
> To my knowledge the versions of said compilers that link against the 
> universal CRT utilize exactly the same Windows APIs (And corresponding 
> dlls) for OS related stuff that Visual C++ itself uses (Minus 
> vcruntime, which is specific to MSVC), without any POSIX compatibility 
> layers on top. I've tried rewiring the build system incrementally in 
> the meantime on my end to see what areas would be of interest and it's 
> now failing when hitting POSIX specific includes during make, hinting 
> that (At least for gcc) compatibility has been traded for full native 
> support for Windows APIs within the compiler, which may mitigate any 
> issues slightly (That's also why I suggested initially to only allow 
> for versions that link against the ucrt without any compatibility 
> layers- Cygwin's toolchains which link against newlib and old MinGW 
> binaries which link against msvcrt would just be an unnecessary 
> headache). That said, whether aforementioned bugs will actually 
> surface should the attempt be successful I don't really know yet
>
>         Actually, I would seriously assume that any other compiler 
> than VS on Windows will give much worse results.
>         The VS compiler is battle-hardened. gcc and clang are only 
> used by a very small enthusiastic hobbyist minority.
>
> The Windows ports of both compilers do keep the same optimizations and 
> code generation quality as they do on other platforms from what I know 
> though, it's mainly the linkers that have been modified to generate 
> the PE format instead of the ELF on Linux. I digress, I don't have any 
> results to show for this yet
>
> I'm not sure I get the part about macOS strictly mapping to clang. 
> Isn't there the option to swap to using gcc for macOS?
No, Apple removed that option years ago.

/Magnus
>
> best regards,
> Julian
>
> On Sat, Mar 12, 2022 at 1:50 AM Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com> wrote:
>
>
>
>     On 2022-03-11 14:34, Julian Waters wrote:
>>     Darn, seems like it'll be much harder than I expected. Since
>>     multiple toolchains are supported for macOS and Linux, I assumed
>>     a slight patch would help get it to work on Windows. Looking
>>     through the stuff in make though, it appears a lot of the build
>>     system implicitly expects the compiler for Windows to always be
>>     Visual C++, which doesn't really help that much (Though the fact
>>     that we can exclude many versions of gcc, such as Cygwin's and
>>     old MinGW binaries helps a lot). The build process for the newer
>>     Windows ports of gcc are surprisingly similar to Visual C++
>>     though (Eg rc can be swapped out for windres) so this might
>>     hopefully be something I can try exploring in the future (Gonna
>>     look a bit harder at make and write what I can find back to this
>>     mailing list in the meantime). It'd be interesting if benchmarks
>>     of the JVM compiled with different compilers on Windows can be
>>     compared side by side on the off chance this becomes a reality though
>
>     In theory OS and compiler toolchain are separate things. In
>     practice, in the JDK, they are not. There is basically a 1-to-1
>     mapping between toolchain and OS:
>     Windows <-> Visual Studio
>     macOS <-> XCode/clang
>     linux <-> gcc
>
>     (The one possible exception is that clang on linux is probably
>     feasible.)
>
>     After years and years on this, all kinds of assumptions has been
>     hard-coded, even if people try to do the right thing. But
>     sometimes it is not clear if you are checking for toolchain or os;
>     perhaps when linking with a specific library, or setting some define.
>
>     Any attempt to change this is, as I said, a *huge* undertaking.
>     *And* there will be tons of negative consequences for the code
>     base as a whole, when trying to differentiate between toolchain
>     and OS. So this will need to be seriously considered.
>
>     /Magnus
>
>>
>>     best regards,
>>     Julian
>>
>>     On Fri, Mar 11, 2022 at 9:16 PM Magnus Ihse Bursie
>>     <magnus.ihse.bursie at oracle.com> wrote:
>>
>>         On 2022-03-11 12:55, Julian Waters wrote:
>>
>>         > Hi all,
>>         >
>>         > How feasible would it be/much effort would it require to
>>         support compiling
>>         > with alternate toolchains on Windows besides Visual C++
>>         (like the Windows
>>         > ports of clang and gcc) if we restrict the allowed
>>         toolchains to only those
>>         > that link against the ucrt? (Toolchains linking against the
>>         dated msvcrt
>>         > would present too many issues to work with)
>>
>>         That'd be a huge undertaking. And any such patch would only
>>         be accepted
>>         into the code base if the organization behinded appeared
>>         trustworthy in
>>         their long-term commitment to keeping it working.
>>
>>         /Magnus
>>
>>
>