On Tue, 3 Sep 2024 17:43:38 GMT, Magnus Ihse Bursie wrote:
>> After JDK-8338404, the build produces warnings like:
>>
>> /bin/tee:
>> /localhome/git/jdk-CDR/build/linux-x64/support/interim-image/jlink.log: No
>> such file or directory
>>
>> Fix this by using a proper SetupExecute instead.
>
>
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Tue, 3 Sep 2024 18:10:06 GMT, Erik Joelsson wrote:
> I'm guessing this would work if I built the regular image first, or at least
> at the same time.
No, I don't think that should matter. `static-jdk-image` depends on
`exploded-image`, and the files in your error message resides in `jdk`, n
On Sun, 1 Sep 2024 06:37:26 GMT, Doug Simon wrote:
> This PR modifies the GitHub Actions product build on Linux to include
> building of the static-libs bundle.
> This is a minimal smoke test to ensure these builds don't break.
This pull request has now been integrated.
Changeset: 130ac13c
Aut
On Tue, 3 Sep 2024 16:15:33 GMT, Erik Joelsson wrote:
>> This PR modifies the GitHub Actions product build on Linux to include
>> building of the static-libs bundle.
>> This is a minimal smoke test to ensure these builds don't break.
>
> I think adding static libs to one platform and flavor comb
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
> After JDK-8338404, the build produces warnings like:
>
> /bin/tee:
> /localhome/git/jdk-CDR/build/linux-x64/support/interim-image/jlink.log: No
> such file or directory
>
> Fix this by using a proper SetupExecute instead.
Magnus Ihse Bursie has updated the pull request incrementally with one
On Tue, 3 Sep 2024 16:10:23 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use PRE_COMMAND instead
>
> make/InterimImage.gmk line 51:
>
>> 49: OUTPUT_DIR := $(INTERIM_IMAGE_DIR), \
>>
On Sun, 1 Sep 2024 06:37:26 GMT, Doug Simon wrote:
> This PR modifies the GitHub Actions product build on Linux to include
> building of the static-libs bundle.
> This is a minimal smoke test to ensure these builds don't break.
Marked as reviewed by ihse (Reviewer).
-
PR Review: h
On Sun, 1 Sep 2024 06:37:26 GMT, Doug Simon wrote:
> This PR modifies the GitHub Actions product build on Linux to include
> building of the static-libs bundle.
> This is a minimal smoke test to ensure these builds don't break.
I think adding static libs to one platform and flavor combination s
On Mon, 2 Sep 2024 12:20:24 GMT, Magnus Ihse Bursie wrote:
> After JDK-8338404, the build produces warnings like:
>
> /bin/tee:
> /localhome/git/jdk-CDR/build/linux-x64/support/interim-image/jlink.log: No
> such file or directory
>
> Fix this by using a proper SetupExecute instead.
Marked as
> 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 `jm
On Mon, 2 Sep 2024 12:28:17 GMT, Magnus Ihse Bursie wrote:
> From the bug report:
>
> Users are reporting warnings like this:
>
> lib/CompileGtest.gmk:84: warning: overriding recipe for target
> '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt'
> lib/CompileJvm.gmk:166: warn
On Fri, 30 Aug 2024 16:27:18 GMT, Magnus Ihse Bursie wrote:
> The build system code has unfortunately diverted in some places from the
> conventions as described in
> https://openjdk.org/groups/build/doc/code-conventions.html.
>
> Instead of trying to fix these when touching code nearby, I'd l
On Mon, 2 Sep 2024 12:28:17 GMT, Magnus Ihse Bursie wrote:
> From the bug report:
>
> Users are reporting warnings like this:
>
> lib/CompileGtest.gmk:84: warning: overriding recipe for target
> '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt'
> lib/CompileJvm.gmk:166: warn
On Sun, 1 Sep 2024 21:35:02 GMT, Magnus Ihse Bursie wrote:
>> The build system code has unfortunately diverted in some places from the
>> conventions as described in
>> https://openjdk.org/groups/build/doc/code-conventions.html.
>>
>> Instead of trying to fix these when touching code nearby, I
On Mon, 2 Sep 2024 08:59:05 GMT, Magnus Ihse Bursie wrote:
> I've done that now, and it looks clean on all platforms. (With one exception:
> we include the vardeps files for jar files in jdk/demos -- historical
> reasons, I assume -- and they look slightly different; but they should not
> real
Hi,
I just wanted to let you know that there is now a PR with an initial
implementation of a static java launcher:
https://github.com/openjdk/jdk/pull/20837
Some noteworthy limitations:
1) Support for hiding local symbols in static libraries are not yet
implemented. This mean that there are
As a prerequisite for Hermetic Java, we need a statically linked `java`
launcher. It should behave like the normal, dynamically linked `java` launcher,
except that all JDK native libraries should be statically, not dynamically,
linked.
This patch is the first step towards this goal. It will gen
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Tue, 3 Sep 2024 07:26:53 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote:
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:66
On Tue, 3 Sep 2024 07:26:53 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
On Thu, 15 Aug 2024 15:32:28 GMT, Fei Gao wrote:
>> This patch enables BTI branch protection for runtime part on Linux/aarch64
>> platform.
>>
>> Motivation
>>
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level
>> packages can gain additional hardening by compiling
On Thu, 15 Aug 2024 15:32:28 GMT, Fei Gao wrote:
>> This patch enables BTI branch protection for runtime part on Linux/aarch64
>> platform.
>>
>> Motivation
>>
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level
>> packages can gain additional hardening by compiling
On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10:
> error: unused variable 'exePath' [-Werror,-Wunused
On Tue, 3 Sep 2024 06:42:42 GMT, Julian Waters wrote:
>> At one stage we started using the idiom:
>>
>> (void) someFunc();
>>
>> to tell the compiler to not warn about the unused result. IIRC that stopped
>> working.
>
> Not entirely sure about clang, but casting to void to silence warnings sh
29 matches
Mail list logo
