I meant in toolchain.m4, which allows gcc for macOS 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 >>> >>> >>> >> >
