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