I think --disable-warnings-as-errors is for C++ warnings, not for java
warnings like deprecation, you can use
-Xlint:none to disable the warning.
But this will not prevent the output of deprecation message, the output is
like:
Note: Test.java uses or overrides a deprecated API.
Note: Recompile
Alright, thank you Thomas, thank you Erik!
Using JDK 19 as boot JDK does make the JDK 20 build work; I didn't know the
recommendation was to use the previous JDK as a boot JDK.
On Fri, 15 Mar 2024 at 17:55, wrote:
> The configure flag --disable-warnings-as-errors only applies to native
>
The configure flag --disable-warnings-as-errors only applies to native
compilation, where the C/C++ compiler is used. For Java compilation,
most of the source code is built using the interim javac, which is
itself built from the JDK src, so we have full control over what
warnings should or
On Fri, 15 Mar 2024 13:17:24 GMT, Julian Waters wrote:
>> Eclipse Shared Workspaces share the same directory as the JDK itself, which
>> does not make much sense since there can be multiple different
>> configurations of the JDK which Eclipse does depend on (as minimalistic as
>> it is), and
Hi Simeon,
not a direct help, and I don't know the answer either, but I ran into
exactly the same problem today and switched to JDK 19 as boot jdk, which
proved a valid workaround.
Cheers, Thomas
On Fri, Mar 15, 2024 at 4:28 PM S A
wrote:
> Hi all,
>
> how do I disable warnings treated as
Hi all,
how do I disable warnings treated as errors during the OpenJDK 19+ build?
In order to better understand changes in behavior between OpenJDK versions,
I've been bisecting and compiling OpenJDK 19 and OpenJDK 20 in the recent
months.
One problem that I run into a lot is warnings failing
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (directory
On Wed, 13 Mar 2024 11:59:36 GMT, Magnus Ihse Bursie wrote:
>> As part of the ongoing effort to enable jcheck whitespace checking to all
>> text files, it is now time to address assembly (.S) files. The hotspot
>> assembly files were fixed as part of the hotspot mapfile removal, so only a
>>
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
On Thu, 14 Mar 2024 12:36:05 GMT, Magnus Ihse Bursie wrote:
> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
> in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
>
> These
On Fri, 15 Mar 2024 11:55:14 GMT, Magnus Ihse Bursie wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - rename
>> - resolve magicus's comments
>
>
> 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
> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
> in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
>
> These flag variables contain a lot of duplication.
>
> The first
> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
> in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
>
> These flag variables contain a lot of duplication.
>
> The first
On Thu, 14 Mar 2024 10:53:49 GMT, Magnus Ihse Bursie wrote:
> We are adding LIBCXX to LIBS in calls to SetupJdkLibrary whenever LINK_TYPE
> is C++. We should do this automatically in SetupJdkLibrary for C++ linking.
>
> I also removed the superfluous `-lc` from some places where it had been
On Fri, 15 Mar 2024 12:42:17 GMT, Erik Joelsson wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains five additional
>>
> Eclipse Shared Workspaces share the same directory as the JDK itself, which
> does not make much sense since there can be multiple different configurations
> of the JDK which Eclipse does depend on (as minimalistic as it is), and there
> is no one true JDK configuration, unlike what this
On Fri, 15 Mar 2024 12:44:49 GMT, Magnus Ihse Bursie wrote:
>> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
>> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`,
>> respectively, in basically all calls to `SetupJdkLibrary` and
>> `SetupJdkExecutable`.
>>
On Fri, 15 Mar 2024 12:39:03 GMT, Magnus Ihse Bursie wrote:
>> make/modules/jdk.jpackage/Lib.gmk line 63:
>>
>>> 61: CXXFLAGS_FILTER_OUT := -MD, \
>>> 62: CXXFLAGS := $(JPACKAGE_APPLAUNCHER_INCLUDES), \
>>> 63: CFLAGS := $(JPACKAGE_APPLAUNCHER_INCLUDES), \
>>
>> This removed `-MD`,
On Fri, 15 Mar 2024 07:15:55 GMT, Julian Waters wrote:
>> Eclipse Shared Workspaces share the same directory as the JDK itself, which
>> does not make much sense since there can be multiple different
>> configurations of the JDK which Eclipse does depend on (as minimalistic as
>> it is), and
> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
> in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
>
> These flag variables contain a lot of duplication.
>
> The first
On Thu, 14 Mar 2024 19:45:10 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix syntax error
>
> make/modules/jdk.jpackage/Lib.gmk line 63:
>
>> 61: CXXFLAGS_FILTER_OUT := -MD, \
>>
On Thu, 14 Mar 2024 14:03:07 GMT, Magnus Ihse Bursie wrote:
>> We are adding LIBCXX to LIBS in calls to SetupJdkLibrary whenever LINK_TYPE
>> is C++. We should do this automatically in SetupJdkLibrary for C++ linking.
>>
>> I also removed the superfluous `-lc` from some places where it had
> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
> in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
>
> These flag variables contain a lot of duplication.
>
> The first
> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
> in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
>
> These flag variables contain a lot of duplication.
>
> The first
On Thu, 14 Mar 2024 18:01:34 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix syntax error
>
> make/common/JdkNativeCompilation.gmk line 206:
>
>> 204: $$(foreach flag,
On Fri, 15 Mar 2024 11:31:08 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
On Thu, 14 Mar 2024 15:29:51 GMT, Andrew Haley wrote:
> > Hi, thanks for continuing with this.
> > As this is similar to SVML, comments applies to x86 also:
> > ```
> > * There is no way to stop the VM from trying to load vmath ?
> > There is both a UseNeon and a UseSVE, if I set both to false
On Thu, 14 Mar 2024 15:25:54 GMT, Andrew Haley wrote:
> > ```
> > * at build time
> >
> > * with/without sleef
> > * with/without sve support
> > ```
>
> What is the relevance of SVE support at build time? Should it matter what the
> build machine is?
>
> Its important to realize that
On Thu, 14 Mar 2024 12:23:17 GMT, Magnus Ihse Bursie wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix variable name in github workflow
>
> src/jdk.incubator.vector/linux/native/libvmath/vect_math.h line 1:
>
>>
On Thu, 14 Mar 2024 15:29:51 GMT, Andrew Haley wrote:
> Hi, thanks for continuing with this.
Thanks for the comments
> As this is similar to SVML, comments applies to x86 also:
>
> * There is no way to stop the VM from trying to load vmath ?
No official way, but deleting libvmath.so will
> 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
On Thu, 14 Mar 2024 20:54:32 GMT, Mandy Chung wrote:
> > The updated patch uses a **build-only** `jlink` plugin, still called
> > `--create-linkable-runtime` which is _a)_ added only at build time with
> > `--add-modules` and _b)_ now generates the diff and prepares the image for
> > runtime
On Thu, 14 Mar 2024 21:16:04 GMT, Erik Joelsson wrote:
> About the configure options,
>
> ```
> --enable-keep-packaged-modules
> enable keeping of packaged modules in jdk image
> [enabled]
> --enable-runtime-link-image
> enable producing
On Wed, 28 Feb 2024 15:19:58 GMT, Julian Waters wrote:
>> Eclipse Shared Workspaces share the same directory as the JDK itself, which
>> does not make much sense since there can be multiple different
>> configurations of the JDK which Eclipse does depend on (as minimalistic as
>> it is), and
> Eclipse Shared Workspaces share the same directory as the JDK itself, which
> does not make much sense since there can be multiple different configurations
> of the JDK which Eclipse does depend on (as minimalistic as it is), and there
> is no one true JDK configuration, unlike what this
36 matches
Mail list logo
