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.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
