Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]
On Tue, 27 Feb 2024 11:09:26 GMT, Magnus Ihse Bursie wrote: > > can we get rid of LDCXX? > > Yeah, that is something I plan to look into. Linking C++ object files with > gcc will fail; and it might be that linking pure C with g++ might be > problematic. If this is the case, I hope we can at least determine this > automatically which linker frontend to use, i.e. selecting g++ as linker > frontend if there is at least one .cpp file in the set of sources. > > This PR is actually a kind of prerequisite for that kind of work. I'd certainly opt for selecting which linker driver to use automatically than using one for both; According to some discussions with several gcc maintainers (https://web.libera.chat/) they really aren't meant to be intermingled Also was fine with LANG; There wasn't a need to change it to LINK_TYPE, but oh well - PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966341897
Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]
On Tue, 27 Feb 2024 08:14:56 GMT, Julian Waters wrote: > can we get rid of LDCXX? Yeah, that is something I plan to look into. Linking C++ object files with gcc will fail; and it might be that linking pure C with g++ might be problematic. If this is the case, I hope we can at least determine this automatically which linker frontend to use, i.e. selecting g++ as linker frontend if there is at least one .cpp file in the set of sources. This PR is actually a kind of prerequisite for that kind of work. - PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966312751
Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]
On Tue, 27 Feb 2024 08:29:44 GMT, Julian Waters wrote: > All those new parameters to SetupNativeCompilation, were they always there > and the comments about them were just missing from the documentation about > the function? Yep. The toolchain definition was a way to "package" multiple arguments to SetupNativeCompilation, so you did not have to specify them individually in each call. But in the end they just turned into "normal" arguments to SetupNativeCompilation (but undocumented...). - PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966314926
Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >> specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the >> default). >> >> There is a single exception to this rule, and that is if we want to compile >> for the build platform rather than the target platform. (This is only done >> for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD >> (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be >> resolved using direct variables to SetupNativeCompilation, instead of first >> creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and >> make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Rename LANG to LINK_TYPE Just a small question by the way: All those new parameters to SetupNativeCompilation, were they always there and the comments about them were just missing from the documentation about the function? - PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966025499
Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]
On Tue, 27 Feb 2024 08:07:38 GMT, Daniel Jeliński wrote: > can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is > `gcc`; I searched for the differences, and the only thing I could find is > that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could > explicitly add these options, and use gcc everywhere. > > See: https://stackoverflow.com/a/172592 > https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html I don't think that's a good idea, the differences between the gcc and g++ drivers are supposed to be (opaque) implementation details. Doing so would make us dependent on internal mechanisms of gcc subject to change between versions and would make bugfixing hard to do if such a change really happened and the linker command line got messed up as a result (This likely would impact clang too, unless I am mistaken?) - PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966002485
Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >> specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the >> default). >> >> There is a single exception to this rule, and that is if we want to compile >> for the build platform rather than the target platform. (This is only done >> for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD >> (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be >> resolved using direct variables to SetupNativeCompilation, instead of first >> creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and >> make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Rename LANG to LINK_TYPE can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is `gcc`; I searched for the differences, and the only thing I could find is that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could explicitly add these options, and use gcc everywhere. See: https://stackoverflow.com/a/172592 https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html - PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965991536
Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, >> but it turned out that we really only need a single toolchain, with a single >> twist: if it should use CC or CPP to link. This is better described by a >> specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the >> default). >> >> There is a single exception to this rule, and that is if we want to compile >> for the build platform rather than the target platform. (This is only done >> for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD >> (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be >> resolved using direct variables to SetupNativeCompilation, instead of first >> creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and >> make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Rename LANG to LINK_TYPE Thanks for the run down on the history of the build system! I'm sorry it took me a day to respond, I must have missed this in my inbox while going over the GitHub activity of the day. Given that the function was meant for the older build system, it now seems reasonable to replace it with this newer solution. In the worst case scenario, a backout is possible, as was suggested. I would have said that LANG is an ok name and that there was no need to rename it to LINK_TYPE after the context given and the knowledge that future work was planned for it, had I read this earlier though :( This is also the first time I've ever had an objection to a Pull Request. Feels weird, really - PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965949353
Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3]
> The idea of setting up general "toolchains" in the native build was good, but > it turned out that we really only need a single toolchain, with a single > twist: if it should use CC or CPP to link. This is better described by a > specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the > default). > > There is a single exception to this rule, and that is if we want to compile > for the build platform rather than the target platform. (This is only done > for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD > (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be > resolved using direct variables to SetupNativeCompilation, instead of first > creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and > make it much clearer if we use the C or C++ linker. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Rename LANG to LINK_TYPE - Changes: - all: https://git.openjdk.org/jdk/pull/17986/files - new: https://git.openjdk.org/jdk/pull/17986/files/f8a18690..5f446abd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=01-02 Stats: 27 lines in 13 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/17986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986 PR: https://git.openjdk.org/jdk/pull/17986
