On Wed, 12 Feb 2025 20:37:26 GMT, Erik Joelsson wrote:
> The new framework for tracing makefile inclusion has a bug. In the
> Make[Include|Snippet]End.gmk files, the variables THIS_INCLUDE and
> THIS_SNIPPET respectively are restored from the HELPER_STACK variable. The
> problem is that we can
On Thu, 29 Aug 2024 11:26:03 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.5.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `requiredVers
On Wed, 12 Feb 2025 08:59:32 GMT, Matthias Baesken wrote:
> This is what I get with HIGH , on Linux x86_64 (gcc 11.3 used)
>
> du -sh images/jdk/lib/libjdwp.* 2.0M images/jdk/lib/libjdwp.debuginfo 316K
> images/jdk/lib/libjdwp.so
So it's about a 5% footprint increase to go from LOW to HIGH, an
On Wed, 12 Feb 2025 21:57:13 GMT, Phil Race wrote:
> The build tasks all succeeded (well, there's a not-relevant windows installer
> one still in progress, so never mind about that).
Thanks again, @prrace! I'll integrate tomorrow early morning.
-
PR Comment: https://git.openjdk.or
On Wed, 12 Feb 2025 23:37:44 GMT, Brian Burkhalter wrote:
> > I think testing should not run into any issue
>
> I did not find any problem for the tests in the
> [jdk_nio](https://github.com/openjdk/jdk/blob/55097dd4cbb5d691c12cb0247d66dce593759d59/test/jdk/TEST.groups#L206)
> group on Linux,
On Wed, 12 Feb 2025 17:26:59 GMT, Jiangli Zhou wrote:
> I think testing should not run into any issue
I did not find any problem for the tests in the
[jdk_nio](https://github.com/openjdk/jdk/blob/55097dd4cbb5d691c12cb0247d66dce593759d59/test/jdk/TEST.groups#L206)
group on Linux, macOS, or Wind
The CFV to Dissolve the JDK 7 and JDK 8 Projects [1] is now closed.
Valid votes cast by Project Members per the census [2] are :
Yes: 5
No: 0
According to the Bylaws definition of Sponsorship [3] and Three-Vote
Consensus [4], this is sufficient to Dissolve the projects.
The project mailing l
On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song wrote:
> The copyright header format check was introduced in
> [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user
> recently reported that the check doesn't catch incorrect copyright headers in
> this pr(https://github.com/op
On Wed, 12 Feb 2025 21:03:02 GMT, Phil Race wrote:
> It might be prudent this time to put this through the Oracle internal build
> system. Not just GHA. I'll submit a build shortly.
Thank you, @prrace!
-
PR Comment: https://git.openjdk.org/jdk/pull/23600#issuecomment-2654882500
On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song wrote:
> The copyright header format check was introduced in
> [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user
> recently reported that the check doesn't catch incorrect copyright headers in
> this pr(https://github.com/op
On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song wrote:
> The copyright header format check was introduced in
> [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user
> recently reported that the check doesn't catch incorrect copyright headers in
> this pr(https://github.com/op
On Wed, 12 Feb 2025 20:19:08 GMT, Jiangli Zhou wrote:
> Please help review this change. The current version calls `FT_Property_Set`
> using the function address returned from `dlsym` for the static case as well.
> This is to avoid build issue on build system using older `libfreetype` that
> do
The new framework for tracing makefile inclusion has a bug. In the
Make[Include|Snippet]End.gmk files, the variables THIS_INCLUDE and THIS_SNIPPET
respectively are restored from the HELPER_STACK variable. The problem is that
we can't know if the next item on the stack is a previous "include" or
On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song wrote:
> The copyright header format check was introduced in
> [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user
> recently reported that the check doesn't catch incorrect copyright headers in
> this pr(https://github.com/op
On Wed, 12 Feb 2025 19:33:15 GMT, Phil Race wrote:
> Looks like you will have to more fully copy the pattern in the dynamic
> linking case.
Yeah, we still have to call it using the function address for the static case.
I sent https://github.com/openjdk/jdk/pull/23600.
-
PR Comme
Please help review this change. The current version calls `FT_Property_Set`
using the function address returned from `dlsym` for the static case as well.
This is to avoid build issue on build system using older `libfreetype` that
does not define `FT_Property_Set`. Thanks for everyone provided in
On Wed, 12 Feb 2025 19:49:42 GMT, Zhao Song wrote:
> The copyright header format check was introduced in
> [JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user
> recently reported that the check doesn't catch incorrect copyright headers in
> this pr(https://github.com/op
The copyright header format check was introduced in
[JDK-8346046](https://bugs.openjdk.org/browse/JDK-8346046). However, a user
recently reported that the check doesn't catch incorrect copyright headers in
this pr(https://github.com/openjdk/jdk/pull/23550).
After investigation, I found that the
On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken wrote:
> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical (and LOW is
> not really low when looking at the opt-flags used).
> But building it with SIZE optimization m
On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou wrote:
> Please review the change that looks up `FT_Property_Set` from the current
> executable first when running on static JDK. If `FT_Property_Set` can be
> found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is
> statically link
On Wed, 12 Feb 2025 18:54:17 GMT, Mikael Vidstedt wrote:
> I can confirm that `FT_Property_Set` does not seem to be there at all in the
> (older?) version of freetype from OL6.4.
Thanks for confirming!
-
PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654591105
On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou wrote:
> Please review the change that looks up `FT_Property_Set` from the current
> executable first when running on static JDK. If `FT_Property_Set` can be
> found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is
> statically link
On Wed, 12 Feb 2025 18:37:11 GMT, Henry Jen wrote:
>> Please review the change that looks up `FT_Property_Set` from the current
>> executable first when running on static JDK. If `FT_Property_Set` can be
>> found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is
>> statically lin
On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou wrote:
> Please review the change that looks up `FT_Property_Set` from the current
> executable first when running on static JDK. If `FT_Property_Set` can be
> found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is
> statically link
On Wed, 12 Feb 2025 18:17:16 GMT, Jiangli Zhou wrote:
> This broke our builds:
>
> ```
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:
> In function 'setInterpreterVersion':
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:307:9:
> er
On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou wrote:
> Please review the change that looks up `FT_Property_Set` from the current
> executable first when running on static JDK. If `FT_Property_Set` can be
> found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is
> statically link
On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov wrote:
> Backout change
> [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd)
> because it causes build failure.
This pull request has now been integrated.
Changeset: 336d0d85
Author:Vladimir Kozlov
On Wed, 12 Feb 2025 17:24:08 GMT, Vladimir Kozlov wrote:
> This broke our builds:
>
> ```
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:
> In function 'setInterpreterVersion':
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:307:9:
>
On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov wrote:
> Backout change
> [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd)
> because it causes build failure.
Looks fine and trivial.
-
Marked as reviewed by shade (Reviewer).
PR Review:
On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov wrote:
> Backout change
> [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd)
> because it causes build failure.
I will wait GHA builds finish
-
PR Comment: https://git.openjdk.org/jdk/pull/2
On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov wrote:
> Backout change
> [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd)
> because it causes build failure.
Looks good. Thanks!
-
Marked as reviewed by jiangli (Reviewer).
PR Review: ht
Backout change
[JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd)
because it causes build failure.
-
Commit messages:
- 8349926: [BACKOUT] Support static JDK in libfontmanager/freetypeScaler.c
Changes: https://git.openjdk.org/jdk/pull/23591/
On Wed, 12 Feb 2025 17:24:39 GMT, Vladimir Kozlov wrote:
> I don't see GHA testing enabled for this repo.
GHA testing is enabled: https://github.com/openjdk/jdk/pull/23574/checks. All
tests passed in GHA.
-
PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654440345
On Wed, 12 Feb 2025 17:26:59 GMT, Jiangli Zhou wrote:
> please let me know your internal testing result.
Sure, of course.
-
PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2654400869
On Wed, 12 Feb 2025 07:00:25 GMT, Alan Bateman wrote:
> @bplb You may have to double check that this works for us.
Thanks!
@bplb, please let me know your internal testing result. If there's no
additional internal test source changes in those native libraries, I think
testing should not run in
On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou wrote:
> Please review the change that looks up `FT_Property_Set` from the current
> executable first when running on static JDK. If `FT_Property_Set` can be
> found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is
> statically link
On Wed, 12 Feb 2025 05:07:08 GMT, Phil Race wrote:
>> Please review the change that looks up `FT_Property_Set` from the current
>> executable first when running on static JDK. If `FT_Property_Set` can be
>> found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is
>> statically lin
On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou wrote:
> Please review the change that looks up `FT_Property_Set` from the current
> executable first when running on static JDK. If `FT_Property_Set` can be
> found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is
> statically link
On Tue, 3 Nov 2020 00:33:09 GMT, Magnus Ihse Bursie wrote:
> If we build a headless only JDK, configure will require X11 libraries and
> headers to be present. This used to be necessary, but thanks to massive
> cleanups in the AWT headless code, this is no longer the case.
>
> We should fix co
On Tue, 11 Feb 2025 17:10:37 GMT, Leonid Mesnik wrote:
>> The fix add remaining classes to the testlibrary jar and fix some warnings
>> in security-related classes.
>
> Leonid Mesnik has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Merge
On Tue, 11 Feb 2025 07:46:54 GMT, Daniel Jeliński wrote:
> `make test TEST=gtest` fails to run gtest on WSL. This is because we're
> looking for a nonexistent file `gtestLauncher`; on Windows the file is named
> `gtestLauncher.exe`.
>
> This PR adds `$EXECUTABLE_SUFFIX` to the executable path,
On Tue, 11 Feb 2025 07:46:54 GMT, Daniel Jeliński wrote:
> `make test TEST=gtest` fails to run gtest on WSL. This is because we're
> looking for a nonexistent file `gtestLauncher`; on Windows the file is named
> `gtestLauncher.exe`.
>
> This PR adds `$EXECUTABLE_SUFFIX` to the executable path,
On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote:
> The libjdwp is currently built with LOW optimization level, it could be built
> with SIZE optimization to lower the lib size by ~ 10 % on UNIX. On Windows
> LOW and SIZE currently translate to the same O1 optimization flag so no
> dif
On Fri, 7 Feb 2025 22:45:15 GMT, Harshitha Onkar wrote:
>>> What tests have you run?
>>
>> Had this in our internal test queue with jtreg / JCK plus some additional
>> SAP internal tests. No issues seen.
>> However I think I have to run some more manual tests on client like setups.
>>
>> Un
On Wed, 12 Feb 2025 08:34:03 GMT, Julian Waters wrote:
> The bug is an Internal Compiler Error, gcc crashes when that flag is on (And
> LTO seems to raise the likelihood of gcc crashing).
Thanks for the details. I never saw this when setting opt-size AND
lto/linktime-opt for libjvm; maybe my g
On Wed, 12 Feb 2025 07:31:39 GMT, Matthias Baesken wrote:
> Do you have an example of a bug caused by the issue you mention (and is this
> already documented in the JBS somewhere) ?
I don't believe this is documented anywhere in the issue tracker, I'll do so in
a moment. The bug is an Internal
On Wed, 12 Feb 2025 08:05:30 GMT, Chris Plummer wrote:
> > LIBJDWP is currently built with optimization level LOW.
>
> Yes, but I'm still now sure why it wasn't always built with HIGH. Is there a
> reason for focusing on footprint here? What is the footprint different
> between HIGH and LOW?
On Wed, 12 Feb 2025 07:29:09 GMT, Matthias Baesken wrote:
> LIBJDWP is currently built with optimization level LOW.
Yes, but I'm still now sure why it wasn't always built with HIGH. Is there a
reason for focusing on footprint here? What is the footprint different between
HIGH and LOW?
---
48 matches
Mail list logo
