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?
best regards,
Julian
On Sat, Mar 12, 2022 at 1:50 AM Magnus Ihse Bursie <
magnus.ihse.bur...@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.bur...@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
>>
>>
>>
>
