Re: RFR: JDK-8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc
On Thu, 28 Mar 2024 16:50:20 GMT, Joachim Kern wrote: > As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building > the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect > clang by another name, and it uses the clang toolchain in the JDK build. Thus > the old xlc toolchain was removed by > [JDK-8327701](https://bugs.openjdk.org/browse/JDK-8327701). > Now we also switch the HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc, removing the > last xlc rudiment. > This means merging the AIX specific content of > utilities/globalDefinitions_xlc.hpp and utilities/compilerWarnings_xlc.hpp > into the corresponding gcc files on the on side and removing the > defined(TARGET_COMPILER_xlc) blocks in the code, because the > defined(TARGET_COMPILER_gcc) blocks work out of the box for the new AIX > compiler. > The rest of the changes are needed because of using > utilities/compilerWarnings_xlc.hpp the compiler is much more nagging about > ill formatted printf That one singular build change looks good :) > The rest of the changes are needed because of using > utilities/compilerWarnings_xlc.hpp the compiler is much more nagging about > ill formatted printf Did you mean compilerWarnings_gcc.hpp? - Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/18536#pullrequestreview-1967860264 PR Comment: https://git.openjdk.org/jdk/pull/18536#issuecomment-2026674128
Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when it is
> time to consider whether to generate the diagnostic or not.
>
> 2. Updates to the `javac` front end to record "dangling docs comments" found
> near the beginning of a declaration, and to report them using an instance of
> `DeferredLintHandler`. This allows the warnings to be enabled or disabled
> using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The
> procedure for handling dangling doc comments is described in this comment in
> `JavacParser`.
>
> * Dangling documentation comments are handled as follows.
> * 1. {@code Scanner} adds all doc comments to a queue of
> * recent doc comments. The queue is flushed whenever
> * it is known that the recent doc comments should be
> * ignored and should not cause any warnings.
> * 2. The primary documentation comment is the one obtained
> * from the first token of any declaration.
> * (using {@code token.getDocComment()}.
> * 3. At the end of the "signature" of the declaration
> * (that is, before any initialization or body for the
> * declaration) any other "recent" comments are saved
> * in a map using the primary comment as a key,
> * using this method, {@code saveDanglingComments}.
> * 4. When the tree node for the declaration is finally
> * available, and the primary comment, if any,
> * is "attached", (in {@link #attach}) any related
> * dangling comments are also attached to the tree node
> * by registering them using the {@link #deferredLintHandler}.
> * 5. (Later) Warnings may be genereated for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` to
> create box or other standout comments.
lgtm
-
Marked as reviewed by vromero (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1967750057
Re: RFR: 8329289: Unify SetupJdkExecutable and SetupJdkLibrary
On Thu, 28 Mar 2024 17:59:10 GMT, Magnus Ihse Bursie wrote: > Currently a lot of code is duplicated between SetupJdkExecutable and > SetupJdkLibrary. Furthermore, some functionality is still missing from > SetupJdkExecutable that is present in SetupJdkLibrary. These functions also > have not had their documentation properly updated as they have evolved. This > PR will fix all of this. Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18537#pullrequestreview-1967391802
Re: RFR: 8329289: Unify SetupJdkExecutable and SetupJdkLibrary
On Thu, 28 Mar 2024 18:27:39 GMT, Erik Joelsson wrote: >> Currently a lot of code is duplicated between SetupJdkExecutable and >> SetupJdkLibrary. Furthermore, some functionality is still missing from >> SetupJdkExecutable that is present in SetupJdkLibrary. These functions also >> have not had their documentation properly updated as they have evolved. This >> PR will fix all of this. > > make/common/JdkNativeCompilation.gmk line 233: > >> 231: # Set the default flags first to be able to override >> 232: $1_CXXFLAGS := $$(filter-out $$($1_CXXFLAGS_FILTER_OUT), >> $$(CXXFLAGS_JDKLIB)) $$($1_CXXFLAGS) >> 233: endif > > I think it makes sense to share all that is actually common between the two > existing macros, but for these conditional adding default flags, it's just a > big if EXECUTABLE do this, otherwise do that. I think in such cases it makes > more sense to keep that logic in the respective specialized macros. The only > drawback would be that the new `SetupJdkNativeCompilation` won't be usable on > its own, but it's not intended to be anyway. Actually, I'm intending on calling SetupJdkNativeCompilation directly in one place, from SetupTestFilesCompilation, which already mixes executable and libraries at it's entry point. So I'd rather keep SetupJdkNativeCompilation working. Also, I plan to follow this up with a PR that splits up the C[XX]FLAGS_JDK[EXE|LIB] into constituent parts and then just select the few that differs between C and C++, LIB and EXE depending on which is chosen. I should perhaps have been clearer about this. - PR Review Comment: https://git.openjdk.org/jdk/pull/18537#discussion_r1543696187
Re: RFR: 8329289: Unify SetupJdkExecutable and SetupJdkLibrary
On Thu, 28 Mar 2024 21:04:48 GMT, Magnus Ihse Bursie wrote: >> make/common/JdkNativeCompilation.gmk line 233: >> >>> 231: # Set the default flags first to be able to override >>> 232: $1_CXXFLAGS := $$(filter-out $$($1_CXXFLAGS_FILTER_OUT), >>> $$(CXXFLAGS_JDKLIB)) $$($1_CXXFLAGS) >>> 233: endif >> >> I think it makes sense to share all that is actually common between the two >> existing macros, but for these conditional adding default flags, it's just a >> big if EXECUTABLE do this, otherwise do that. I think in such cases it makes >> more sense to keep that logic in the respective specialized macros. The only >> drawback would be that the new `SetupJdkNativeCompilation` won't be usable >> on its own, but it's not intended to be anyway. > > Actually, I'm intending on calling SetupJdkNativeCompilation directly in one > place, from SetupTestFilesCompilation, which already mixes executable and > libraries at it's entry point. So I'd rather keep SetupJdkNativeCompilation > working. > > Also, I plan to follow this up with a PR that splits up the > C[XX]FLAGS_JDK[EXE|LIB] into constituent parts and then just select the few > that differs between C and C++, LIB and EXE depending on which is chosen. I > should perhaps have been clearer about this. I also see another couple of rounds of refactoring on SetupJdkNativeCompilation and SetupNativeCompilation before they get really into shape. I prefer to do that step by step, so it is possible to follow what changes are being done. If I were to make all changes I'd like and push it in a single PR, it would be very hard to follow how the code has been transformed. - PR Review Comment: https://git.openjdk.org/jdk/pull/18537#discussion_r1543708289
Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4]
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks >> >> This is a continuation of work based on [1] by @XiaohongGong, most work was >> done in that pr. In this new pr, just rebased the code in [1], then added >> some minor changes (renaming of calling method, add libsleef as extra lib in >> CI cross-build on aarch64 in github workflow); I aslo tested the combination >> of following scenarios: >> * at build time >> * with/without sleef >> * with/without sve support >> * at runtime >> * with/without sleef >> * with/without sve support >> >> [1] https://github.com/openjdk/jdk/pull/16234 >> >> ## Regression Test >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> ## Performance Test >> Previously, @XiaohongGong has shared the data: >> https://github.com/openjdk/jdk/pull/16234#issuecomment-1767727028 > > Hamlin Li has updated the pull request incrementally with one additional > commit since the last revision: > > fix jni includes Hamlin, thank you for working on this. I think integrating a sub-set of SLEEF is valuable (not all of it makes sense e.g., DFT part). My recommendation would be to focus on a PR that integrates the required source, rather taking steps towards that. AFAICT from browsing prior comments "integrate the source" appears to be the generally preferred solution, but there is some understandable hesitancy about legal aspects. IIUC from what you say this is a technically feasible and maintainable solution. As said here: > We (Oracle Java Platform Group) can handle the required "paperwork https://github.com/openjdk/jdk/pull/16234#issuecomment-1823335443 - PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2025878452
Re: RFR: 8329292: Fix missing cleanups in java.management and jdk.management
On Thu, 28 Mar 2024 18:22:27 GMT, Magnus Ihse Bursie wrote: > For some reason, I missed adding the new standard header for SetupJdkLibrary > in java.management and jdk.management. I also missed to remove a now > superfluous CFLAGS_JDKLIB in libmanagement_ext. Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18538#pullrequestreview-1966969956
Re: RFR: 8329289: Unify SetupJdkExecutable and SetupJdkLibrary
On Thu, 28 Mar 2024 17:59:10 GMT, Magnus Ihse Bursie wrote: > Currently a lot of code is duplicated between SetupJdkExecutable and > SetupJdkLibrary. Furthermore, some functionality is still missing from > SetupJdkExecutable that is present in SetupJdkLibrary. These functions also > have not had their documentation properly updated as they have evolved. This > PR will fix all of this. make/common/JdkNativeCompilation.gmk line 233: > 231: # Set the default flags first to be able to override > 232: $1_CXXFLAGS := $$(filter-out $$($1_CXXFLAGS_FILTER_OUT), > $$(CXXFLAGS_JDKLIB)) $$($1_CXXFLAGS) > 233: endif I think it makes sense to share all that is actually common between the two existing macros, but for these conditional adding default flags, it's just a big if EXECUTABLE do this, otherwise do that. I think in such cases it makes more sense to keep that logic in the respective specialized macros. The only drawback would be that the new `SetupJdkNativeCompilation` won't be usable on its own, but it's not intended to be anyway. - PR Review Comment: https://git.openjdk.org/jdk/pull/18537#discussion_r1543439808
RFR: 8329292: Fix missing cleanups in java.management and jdk.management
For some reason, I missed adding the new standard header for SetupJdkLibrary in java.management and jdk.management. I also missed to remove a now superfluous CFLAGS_JDKLIB in libmanagement_ext. - Commit messages: - 8329292: Fix missing cleanups in java.management and jdk.management Changes: https://git.openjdk.org/jdk/pull/18538/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18538=00 Issue: https://bugs.openjdk.org/browse/JDK-8329292 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18538/head:pull/18538 PR: https://git.openjdk.org/jdk/pull/18538
Re: RFR: 8329289: Unify SetupJdkExecutable and SetupJdkLibrary
On Thu, 28 Mar 2024 17:59:10 GMT, Magnus Ihse Bursie wrote: > Currently a lot of code is duplicated between SetupJdkExecutable and > SetupJdkLibrary. Furthermore, some functionality is still missing from > SetupJdkExecutable that is present in SetupJdkLibrary. These functions also > have not had their documentation properly updated as they have evolved. This > PR will fix all of this. Using COMPARE_BUILD, there is no changes to any executables or production libraries. However, for some reason the gtest libjvm.so is 8 bytes larger on linux-x64. I can't really tell what causes this. It might be a problem with reproducible builds, or perhaps that some command line arguments has been reordered. I don't think it matters. - PR Comment: https://git.openjdk.org/jdk/pull/18537#issuecomment-2025812957
RFR: 8329289: Unify SetupJdkExecutable and SetupJdkLibrary
Currently a lot of code is duplicated between SetupJdkExecutable and SetupJdkLibrary. Furthermore, some functionality is still missing from SetupJdkExecutable that is present in SetupJdkLibrary. These functions also have not had their documentation properly updated as they have evolved. This PR will fix all of this. - Commit messages: - FIx documentation - Remove FindSrcDirsForLib - Unify and simplify code - Merge SetupJdkExecutable and SetupJdkLibrary into SetupJdkNativeCompilation Changes: https://git.openjdk.org/jdk/pull/18537/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18537=00 Issue: https://bugs.openjdk.org/browse/JDK-8329289 Stats: 170 lines in 1 file changed: 52 ins; 83 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/18537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18537/head:pull/18537 PR: https://git.openjdk.org/jdk/pull/18537
Re: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation Comments [v43]
On Thu, 29 Feb 2024 11:39:41 GMT, Hannes Wallnöfer wrote: >> Setext headings only come in "level 1" and "level 2" flavors. >> And, at the time the renderer sees the AST, the difference between ATX and >> setext headings is erased. They're just "headings". >> >> I also think it is better to have a simple rule than an "adaptive" rule. If >> you start doing a more complex rule, you have to consider the effect on >> subheadings as well. > > I suspected it was about the limited range of Setext headings. Yesterday my > proposal was intentionally vague, but thinking about this again I think we > should actually do the simplest and least intrusive thing possible: > > // minLevel is 4 for members, 2 for page-level elements, 1 for doc files > "h" + Math.max(heading.getLevel(), minLevel); > > This arguably generates the correct heading for most simple use cases. What > it doesn't do is to translate whole hierarchies of headings, but I would > argue that few people people need this and those who do should figure out the > rules and use the correct ATX headings. Generally, I disagree with the policy here. In particular, this suggestion "squashes"/"merges" heading levels at the more significant end of the range (i.e. h1, h2) and not at the least significant end of the range (i.e. h5, h6). And, while we do specify the required heading levels in "traditional" doc comments, that seems less than optimal. (I note in times past we had to _modify_ the headings in doc comments as a result of the policy). Given all that, it seems better/simpler to specify that an author should start the headings in any comment at level 1 and have the tool adjust the level as needed. - PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1543389787
Re: RFR: JDK-8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc
On Thu, 28 Mar 2024 16:53:39 GMT, Joachim Kern wrote: >> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building >> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect >> clang by another name, and it uses the clang toolchain in the JDK build. >> Thus the old xlc toolchain was removed by >> [JDK-8327701](https://bugs.openjdk.org/browse/JDK-8327701). >> Now we also switch the HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc, removing the >> last xlc rudiment. >> This means merging the AIX specific content of >> utilities/globalDefinitions_xlc.hpp and utilities/compilerWarnings_xlc.hpp >> into the corresponding gcc files on the on side and removing the >> defined(TARGET_COMPILER_xlc) blocks in the code, because the >> defined(TARGET_COMPILER_gcc) blocks work out of the box for the new AIX >> compiler. >> The rest of the changes are needed because of using >> utilities/compilerWarnings_xlc.hpp the compiler is much more nagging about >> ill formatted printf > > src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 83: > >> 81: #error "xlc version not supported, macro __open_xl_version__ not found" >> 82: #endif >> 83: #endif // AIX > > This `#ifdef _AIX` might be obsolete, because configure will throw a warning > if the compiler has a lower version, but it's only a warning. I'd prefer having less AIX specific parts in this file. Can this be moved somewhere else? Or maybe combine it with the AIX code above? - PR Review Comment: https://git.openjdk.org/jdk/pull/18536#discussion_r1543371129
Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4]
On Mon, 25 Mar 2024 15:13:54 GMT, Andrew Haley wrote: >> Hamlin Li has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix jni includes > >> > > But that raises an interesting question. What happens if you try to load >> > > a library compiled with `-march=armv8-a+sve` on a non-SVE system? Is the >> > > ELF flagged to require SVE so it will fail to load? I'm hoping this is >> > > the case -- if so, everything will work as it should in this PR, but I >> > > honestly don't know. (After spending like 10 years working with >> > > building, I still discover things I need to learn...). >> > >> > >> > I think we can handle it, when a jdk built with sve support runs on a >> > non-sve machine, the sve related code will not be executed with the >> > protection of UseSVE vm flag which is detected at runtime startup. >> >> First of all, my question was of a more general nature. Is there such a >> mechanism in the dynamic linker that protects us from loading libraries that >> will fail if an ISA extension is used that is missing on the running system? >> Or do the linker just check that the ELF is for the right CPU? > > That shouldn't matter to us. If the machine we're running on doesn't support > what we need, why should we even try to open it? > >> Secondly, I assume that libsleef.so proper needs to be compiled with SVE >> support as well. So if we were to skip the shim vectormath library and load >> libsleef directly from hotspot, what would happen then? >> >> Thirdly, the check with UseSVE happens _after_ you load the library. > > At best that's a waste of time during startup. > 2. depends on external sleef at run time only, like @theRealAph suggested. > Cons: requires sleef installed in system at runtime > 3. depends on external sleef at build time only, like @magicus suggested. > Cons: requires sleef installed in system at build time It seem like everyone wants sleef as a "backend". As we have hard time, at least now, integrating sleef, and doing both or one above, doesn't interfere with such integration. And it doesn't hurt anyone if Hamlin is willing to put in the effort. I'd say go head with something like that. - PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2025721135
Re: RFR: JDK-8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc
On Thu, 28 Mar 2024 16:50:20 GMT, Joachim Kern wrote:
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the old xlc toolchain was removed by
> [JDK-8327701](https://bugs.openjdk.org/browse/JDK-8327701).
> Now we also switch the HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc, removing the
> last xlc rudiment.
> This means merging the AIX specific content of
> utilities/globalDefinitions_xlc.hpp and utilities/compilerWarnings_xlc.hpp
> into the corresponding gcc files on the on side and removing the
> defined(TARGET_COMPILER_xlc) blocks in the code, because the
> defined(TARGET_COMPILER_gcc) blocks work out of the box for the new AIX
> compiler.
> The rest of the changes are needed because of using
> utilities/compilerWarnings_xlc.hpp the compiler is much more nagging about
> ill formatted printf
src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 50:
> 48: #undef malloc
> 49: extern void *malloc(size_t) asm("vec_malloc");
> 50: #endif
This `#if` is not needed if we are building on AIX 7.2 TL5 SP7 or higher. This
is the case in our build environment, but I think IBM is still building with
SP5, which would run into build errors if I remove this `#if` now.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18536#discussion_r1543312492
Re: RFR: JDK-8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc
On Thu, 28 Mar 2024 16:50:20 GMT, Joachim Kern wrote: > As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building > the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect > clang by another name, and it uses the clang toolchain in the JDK build. Thus > the old xlc toolchain was removed by > [JDK-8327701](https://bugs.openjdk.org/browse/JDK-8327701). > Now we also switch the HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc, removing the > last xlc rudiment. > This means merging the AIX specific content of > utilities/globalDefinitions_xlc.hpp and utilities/compilerWarnings_xlc.hpp > into the corresponding gcc files on the on side and removing the > defined(TARGET_COMPILER_xlc) blocks in the code, because the > defined(TARGET_COMPILER_gcc) blocks work out of the box for the new AIX > compiler. > The rest of the changes are needed because of using > utilities/compilerWarnings_xlc.hpp the compiler is much more nagging about > ill formatted printf src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 83: > 81: #error "xlc version not supported, macro __open_xl_version__ not found" > 82: #endif > 83: #endif // AIX This `#ifdef _AIX` might be obsolete, because configure will throw a warning if the compiler has a lower version, but it's only a warning. - PR Review Comment: https://git.openjdk.org/jdk/pull/18536#discussion_r1543307859
RFR: JDK-8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc
As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain was removed by [JDK-8327701](https://bugs.openjdk.org/browse/JDK-8327701). Now we also switch the HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc, removing the last xlc rudiment. This means merging the AIX specific content of utilities/globalDefinitions_xlc.hpp and utilities/compilerWarnings_xlc.hpp into the corresponding gcc files on the on side and removing the defined(TARGET_COMPILER_xlc) blocks in the code, because the defined(TARGET_COMPILER_gcc) blocks work out of the box for the new AIX compiler. The rest of the changes are needed because of using utilities/compilerWarnings_xlc.hpp the compiler is much more nagging about ill formatted printf - Commit messages: - JDK-8329257 Changes: https://git.openjdk.org/jdk/pull/18536/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18536=00 Issue: https://bugs.openjdk.org/browse/JDK-8329257 Stats: 261 lines in 13 files changed: 21 ins; 208 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/18536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18536/head:pull/18536 PR: https://git.openjdk.org/jdk/pull/18536
Re: RFR: 8329131: Fold libjli_static back into libjli on AIX
On Thu, 28 Mar 2024 11:30:14 GMT, Magnus Ihse Bursie wrote: > I have pushed what I believe should be a fix. OK, great. Testing started. I'll let you know the results. - PR Comment: https://git.openjdk.org/jdk/pull/18497#issuecomment-2025609933
Re: RFR: 8329131: Fold libjli_static back into libjli on AIX
On Tue, 26 Mar 2024 19:30:01 GMT, Magnus Ihse Bursie wrote: > On AIX, we need a static libjli, since the linker cannot find other libraries > (like libjvm.so and libjava.so) using a relative path, as on other platforms. > > However, for reasons unclear, we still build a dynamic libjli.so on AIX, even > though this is never used. Instead, we also build a static libjli_static.a > library (which is then forced to have a different name as to not collide with > the dynamic library). > > This should be fixed. We should build exactly one libjli on all platforms, be > it static or dynamic. I have pushed what I believe should be a fix. - PR Comment: https://git.openjdk.org/jdk/pull/18497#issuecomment-2024963246
Re: RFR: 8329131: Fold libjli_static back into libjli on AIX [v2]
> On AIX, we need a static libjli, since the linker cannot find other libraries > (like libjvm.so and libjava.so) using a relative path, as on other platforms. > > However, for reasons unclear, we still build a dynamic libjli.so on AIX, even > though this is never used. Instead, we also build a static libjli_static.a > library (which is then forced to have a different name as to not collide with > the dynamic library). > > This should be fixed. We should build exactly one libjli on all platforms, be > it static or dynamic. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Attempted fix for exeJliLaunchTest - Changes: - all: https://git.openjdk.org/jdk/pull/18497/files - new: https://git.openjdk.org/jdk/pull/18497/files/c6f396d1..0533060c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18497=01 - incr: https://webrevs.openjdk.org/?repo=jdk=18497=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18497/head:pull/18497 PR: https://git.openjdk.org/jdk/pull/18497
Re: RFR: 8329131: Fold libjli_static back into libjli on AIX
On Tue, 26 Mar 2024 19:30:01 GMT, Magnus Ihse Bursie wrote: > On AIX, we need a static libjli, since the linker cannot find other libraries > (like libjvm.so and libjava.so) using a relative path, as on other platforms. > > However, for reasons unclear, we still build a dynamic libjli.so on AIX, even > though this is never used. Instead, we also build a static libjli_static.a > library (which is then forced to have a different name as to not collide with > the dynamic library). > > This should be fixed. We should build exactly one libjli on all platforms, be > it static or dynamic. Aaahhh... there is a test that uses jli. I did not think of that. *sigh* Ok, back to the drawing board. - PR Comment: https://git.openjdk.org/jdk/pull/18497#issuecomment-2024904327
Re: RFR: 8329131: Fold libjli_static back into libjli on AIX
On Tue, 26 Mar 2024 19:30:01 GMT, Magnus Ihse Bursie wrote: > On AIX, we need a static libjli, since the linker cannot find other libraries > (like libjvm.so and libjava.so) using a relative path, as on other platforms. > > However, for reasons unclear, we still build a dynamic libjli.so on AIX, even > though this is never used. Instead, we also build a static libjli_static.a > library (which is then forced to have a different name as to not collide with > the dynamic library). > > This should be fixed. We should build exactly one libjli on all platforms, be > it static or dynamic. Unfortunately the AIX build fails with this patch * For target support_test_jdk_jtreg_native_support_exeJliLaunchTest_BUILD_TEST_exeJliLaunchTest_link: ld: 0706-006 Cannot find or open library file: -l jli ld:open(): No such file or directory .ibm-clang: error: linker command failed with exit code 255 (use -v to see invocation) - PR Comment: https://git.openjdk.org/jdk/pull/18497#issuecomment-2024638873
Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v70]
> We should set the -permissive- flag for the Microsoft Visual C compiler, as > was requested by the now backed out > [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes > the Visual C compiler much less accepting of ill formed code, which will > improve code quality on Windows in the future. Julian Waters has updated the pull request incrementally with four additional commits since the last revision: - Labels to empty line in awt_Window.cpp - Labels to empty line in awt_Window.cpp - Label to empty line in awt_Window.cpp - Label to empty line in awt_Window.cpp - Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/ee0297a6..04e3cce1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=15096=69 - incr: https://webrevs.openjdk.org/?repo=jdk=15096=68-69 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096
Integrated: 8329178: Clean up jdk.accessibility native compilation
On Wed, 27 Mar 2024 12:00:28 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on JDK-8328680, making the same kind of cleanup to > jdk.accessibility. The code here needed more work than for the other modules, > so I wanted have it in a separate PR to get a more thorough review. This pull request has now been integrated. Changeset: d580bcf9 Author:Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/d580bcf956d6e1e61aba142d7b639bc5ae26a17c Stats: 108 lines in 2 files changed: 32 ins; 33 del; 43 mod 8329178: Clean up jdk.accessibility native compilation Reviewed-by: erikj, prr - PR: https://git.openjdk.org/jdk/pull/18510
