Supporting alternative toolchains on Windows

Mon Mar 14 13:48:51 UTC 2022

On 2022-03-11 23:17, Julian Waters wrote:
> I meant in toolchain.m4, which allows gcc for macOS

Apple used to ship GCC as part of Xcode, and the original Mac port of 
OpenJDK used that GCC. This was eventually removed from Xcode and the 
OpenJDK build was changed to use Clang instead. To make the transition 
smoother, as we can't expect all OpenJDK builders to change Xcode 
versions at the same time, we left dual support in the build, and we 
never got around to removing the GCC support. There is still a GCC 
launcher in Xcode, but it's just a wrapper for Clang. AFAIK, we have 
never supported any other compiler than the one in Xcode on Macos.

So while toolchain.m4 may make it look like we support GCC on Macos, 
that isn't actually the case. We only support Xcode, and I very much 
doubt we can still build with an Xcode old enough to still include an 
actual GCC.

/Erik

> best regards,
> Julian
>
> On Sat, Mar 12, 2022 at 4:32 AM Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
>> 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
>>>>
>>>>
>>>>