On Mon, 2 Oct 2023 14:13:23 GMT, Erik Joelsson wrote:
>>> What effect will this have on debugging?
>>
>> Hi @erikj79
>> So this is the same as we pathmap the openjdk workspace source just above,
>> in that we only do it when ALLOW_ABSOLUTE_PATHS_IN_OUTPUT is "false", which
>> is for release b
On Mon, 2 Oct 2023 10:31:41 GMT, Andrew Leonard wrote:
> When doing a reproducible Windows build on two different machines, that
> happen to have MS Visual Studio installed in different paths, the resulting
> builds are not identical. This is due to the System include paths, eg:
>
[JDK-8317340](https://bugs.openjdk.org/browse/JDK-8317340) introduced
-pathmap'ing of VS_INCLUDE paths to enable reproducible Windows builds that are
not dependent on the Visual Studio tooling install location. This however
requires pathmap'ing the Windows long paths generated by the compiler, w
On Fri, 6 Oct 2023 10:17:25 GMT, Andrew Leonard wrote:
> [JDK-8317340](https://bugs.openjdk.org/browse/JDK-8317340) introduced
> -pathmap'ing of VS_INCLUDE paths to enable reproducible Windows builds that
> are not dependent on the Visual Studio tooling install location
On Fri, 6 Oct 2023 12:56:17 GMT, Erik Joelsson wrote:
> Could you add a comment on the new UTIL_FIXUP_WIN_LONG_PATH macro that it
> only works in cygwin?
Yes, good point. Added
-
PR Comment: https://git.openjdk.org/jdk/pull/16069#issuecomment-1750638935
paths generated by the compiler, which
> is no easy task within WSL.
>
> This PR excludes the VS include pathmap'ing within WSL, which will mean for
> reproducible builds on WSL, the same VS install location must be used.
Andrew Leonard has updated the pull request incrementall
On Fri, 6 Oct 2023 10:17:25 GMT, Andrew Leonard wrote:
> [JDK-8317340](https://bugs.openjdk.org/browse/JDK-8317340) introduced
> -pathmap'ing of VS_INCLUDE paths to enable reproducible Windows builds that
> are not dependent on the Visual Studio tooling install location
Does anyone know why the jdk8u toolchain_windows.m4 VS_DESCRIPTION_2017
description contains "CURRENTLY NOT WORKING" ?
https://github.com/openjdk/jdk8u/blob/b24b03f9dbeb2c1e8b5cb0279659eee489bd9df4/common/autoconf/toolchain_windows.m4#L74
Thanks
the build working again until a later JDK
> release.
>
> /Erik
>
> On 10/16/23 07:59, Andrew Leonard wrote:
> > Does anyone know why the jdk8u toolchain_windows.m4
> > VS_DESCRIPTION_2017 description contains "CURRENTLY NOT WORKING"
For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR
finds the location of the gcc system include paths, and adds -fdebug-prefix-map
flags to map them to a standard location. Thus making the debuginfo and
resulting libraries reproducible when using DevKits in different path
This PR adds --with-debug-prefix-map to the building of gcc in the DevKit make
file to map the top OUTPUT_ROOT folder to a standard "devkit" path, thus
ensuring DevKit builds are reproducible regardless of the folder the DevKit is
built within.
-
Commit messages:
- 8323671: DevKit
> This PR adds --with-debug-prefix-map to the building of gcc in the DevKit
> make file to map the top OUTPUT_ROOT folder to a standard "devkit" path, thus
> ensuring DevKit builds are reproducible regardless of the folder the DevKit
> is built within.
Andrew Leonar
On Fri, 12 Jan 2024 15:13:26 GMT, Erik Joelsson wrote:
>> Andrew Leonard 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 contai
g DevKits in
> different path locations.
Andrew Leonard 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 four additional
commits since the last revisi
On Fri, 12 Jan 2024 14:47:55 GMT, Andrew Leonard wrote:
> This PR adds --with-debug-prefix-map to the building of gcc in the DevKit
> make file to map the top OUTPUT_ROOT folder to a standard "devkit" path, thus
> ensuring DevKit builds are reproducible regardless of th
On Mon, 15 Jan 2024 14:38:58 GMT, Andrew Leonard wrote:
>> For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR
>> finds the location of the gcc system include paths, and adds
>> -fdebug-prefix-map flags to map them to a standard location. Thus making
On Mon, 15 Jan 2024 14:38:58 GMT, Andrew Leonard wrote:
>> For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR
>> finds the location of the gcc system include paths, and adds
>> -fdebug-prefix-map flags to map them to a standard location. Thus making
On Tue, 16 Jan 2024 12:53:52 GMT, Magnus Ihse Bursie wrote:
>> Andrew Leonard 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 contai
On Tue, 16 Jan 2024 12:52:13 GMT, Magnus Ihse Bursie wrote:
>> make/autoconf/flags-cflags.m4 line 124:
>>
>>> 122: fi
>>> 123:
>>> 124: if test "x$DEBUG_PREFIX_CFLAGS" != x; then
>>
>> Should this test not be inside the "if $ALLOW_ABSOLUTE_PATHS_IN_OUTPUT ==
>> false" block?
>>
>> ed
g DevKits in
> different path locations.
Andrew Leonard has updated the pull request incrementally with one additional
commit since the last revision:
8323667: Library debug files contain non-reproducible full gcc include paths
Signed-off-by: Andrew Leonard
-
Changes:
On Tue, 16 Jan 2024 13:53:59 GMT, Andrew Leonard wrote:
>> The logic of this is a bit strange. I think what we really want to express
>> is:
>>
>> if ! ALLOW_ABSOLUTE_PATHS_IN_OUTPUT and -fdebug-prefix-map is a valid option
>> for gcc then
>> set -fdebu
g DevKits in
> different path locations.
Andrew Leonard has updated the pull request incrementally with one additional
commit since the last revision:
8323667: Library debug files contain non-reproducible full gcc include paths
Signed-off-by: Andrew Leonard
-
Changes:
On Tue, 16 Jan 2024 13:58:51 GMT, Andrew Leonard wrote:
>> @magicus Yes, good point the condition is sort of hidden as it is.
>> I've moved the DEBUG_PREFIX_MAP_GCC_INCLUDE_PATHS setting prior to the
>> compiler option check, so the whole constructed DEBUG_PREFIX_CFLAGS
On Tue, 16 Jan 2024 12:55:47 GMT, Magnus Ihse Bursie wrote:
> Have you checked with `strings` if there are any other hard-coded paths, or
> are these really the only ones left?
I have been doing some separate machine/location builds with DevKits located in
different paths and build workspace i
On Tue, 16 Jan 2024 20:35:01 GMT, Erik Joelsson wrote:
> I think this looks ok but could you split the longer lines to make side by
> side comparisons easier in the future?
Yep, done, thanks Erik
-
PR Comment: https://git.openjdk.org/jdk/pull/17399#issuecomment-1895402691
g DevKits in
> different path locations.
Andrew Leonard has updated the pull request incrementally with one additional
commit since the last revision:
8323667: Library debug files contain non-reproducible full gcc include paths
Signed-off-by: Andrew Leonard
-
Changes:
On Tue, 16 Jan 2024 21:35:14 GMT, Magnus Ihse Bursie wrote:
> So `$CC $CFLAGS` did not work?
@magicus
So I purposely chose SYSROOT_CFLAGS thinking that would all that would be
needed, but I think you're correct, I should use the complete CFLAGS in case a
custom user extension include may have
On Wed, 17 Jan 2024 13:52:39 GMT, Erik Joelsson wrote:
> > > So `$CC $CFLAGS` did not work?
> >
> >
> > @magicus So I purposely chose SYSROOT_CFLAGS thinking that would all that
> > would be needed, but I think you're correct, I should use the complete
> > CFLAGS in case a custom user extensi
g DevKits in
> different path locations.
Andrew Leonard has updated the pull request incrementally with one additional
commit since the last revision:
8323667: Library debug files contain non-reproducible full gcc include paths
Signed-off-by: Andrew Leonard
-
Changes:
On Wed, 17 Jan 2024 15:49:10 GMT, Andrew Leonard wrote:
> > > So `$CC $CFLAGS` did not work?
> >
> >
> > @magicus So I purposely chose SYSROOT_CFLAGS thinking that would all that
> > would be needed, but I think you're correct, I should use the comp
On Fri, 12 Jan 2024 14:33:01 GMT, Andrew Leonard wrote:
> For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR
> finds the location of the gcc system include paths, and adds
> -fdebug-prefix-map flags to map them to a standard location. Thus making the
> d
Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR
when absolute paths are not allowed in the binaries, thus making the building
of a JDK identically reproducible from different build directories.
-
Commit messages:
- 8326685: Linux builds not reproducibl
On Mon, 26 Feb 2024 16:00:42 GMT, Andrew Leonard wrote:
> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR
> when absolute paths are not allowed in the binaries, thus making the building
> of a JDK identically reproducible from different build direct
On Mon, 26 Feb 2024 22:05:34 GMT, Erik Joelsson wrote:
>> I have not thought this fully through, but just throwing out a question:
>> would this work even if one build directory were inside the workspace root,
>> and the other not?
>
> Oh you are right, we should always add the OUTPUTDIR to bot
On Tue, 27 Feb 2024 08:13:07 GMT, Andrew Leonard wrote:
>> Oh you are right, we should always add the OUTPUTDIR to both maps regardless
>> of if it's internal to the WORKSPACE_ROOT or not. Paths relative to the
>> OUTPUTDIR should be stable across builds in diffe
On Tue, 27 Feb 2024 10:35:20 GMT, Magnus Ihse Bursie wrote:
>> It seems correct to include the output dir in the remapping, but I have two
>> objections/questions to the way you are doing it.
>> 1) Why not just use OUTPUTDIR instead of the two specialized subdirs? That
>> is simpler, more gener
On Tue, 27 Feb 2024 10:59:54 GMT, Andrew Leonard wrote:
>> Also, this mapping business is getting really convoluted. :-( I did not like
>> it as it was, and this patch makes it even worse. I think we need to rewrite
>> this to create some kind of dict/map, and then iterat
On Tue, 27 Feb 2024 10:35:20 GMT, Magnus Ihse Bursie wrote:
>> It seems correct to include the output dir in the remapping, but I have two
>> objections/questions to the way you are doing it.
>> 1) Why not just use OUTPUTDIR instead of the two specialized subdirs? That
>> is simpler, more gener
> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR
> when absolute paths are not allowed in the binaries, thus making the building
> of a JDK identically reproducible from different build directories.
Andrew Leonard has updated the pull request incr
> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR
> when absolute paths are not allowed in the binaries, thus making the building
> of a JDK identically reproducible from different build directories.
Andrew Leonard has updated the pull request incr
On Tue, 27 Feb 2024 13:44:15 GMT, Andrew Leonard wrote:
>> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and
>> HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus
>> making the building of a JDK identically reproducible from differen
On Mon, 26 Feb 2024 16:00:42 GMT, Andrew Leonard wrote:
> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR
> when absolute paths are not allowed in the binaries, thus making the building
> of a JDK identically reproducible from different build dire
lly a "test", and I suspect
most vendors will either just do a standard "product-images" build, or
perform their own bootcycle by doing two builds...
Cheers
Andrew
On Wed, Sep 20, 2023 at 2:44 PM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 20
with the reproducibility
> issue. I would support that change. I don't think we can reasonably do
> something about the jar tool.
>
> /Erik
> On 9/20/23 08:12, Andrew Leonard wrote:
>
> Hi Magnus,
>
> So yes, jrt-fs.jar can be different between a normal build and a boot
bootcycle builds to produce their JDK binaries.
>
> Switching the compiler to interim would help with the reproducibility
> issue. I would support that change. I don't think we can reasonably do
> something about the jar tool.
>
> /Erik
> On 9/20/23 08:12, Andrew Leonard
Thanks Magnus, yeah it is still doing as it says on the "tin", so I think
i'm just being paranoid! I'll put a PR together for review, cheers
On Thu, Sep 21, 2023 at 10:49 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2023-09-21 10:59, Andr
jrt-fs.jar classes are currently compiled with the BootJDK being used, this has
a couple of issues:
- The classes are not reproducible between a standard and bootcycle build
image, since the first is compiled by jdk-N-1 and the later jdk-N
- The jrt-fs classes in a standard product image are comp
On Fri, 22 Sep 2023 12:38:03 GMT, Andrew Leonard wrote:
> jrt-fs.jar classes are currently compiled with the BootJDK being used, this
> has a couple of issues:
> - The classes are not reproducible between a standard and bootcycle build
> image, since the first is compiled by jdk
When doing a reproducible Windows build on two different machines, that
happen to have MS Visual Studio installed in different paths, the resulting
builds are not identical. This is due to the System include paths, eg:
C:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Tools\MSVC\14.37.32
On Mon, 2 Oct 2023 13:39:43 GMT, Erik Joelsson wrote:
> What effect will this have on debugging?
Hi @erikj79
So this is the same as we pathmap the openjdk workspace source just above, in
that we only do it when ALLOW_ABSOLUTE_PATHS_IN_OUTPUT is "false", which is for
release builds.
For "debug
On Mon, 2 Oct 2023 10:31:41 GMT, Andrew Leonard wrote:
> When doing a reproducible Windows build on two different machines, that
> happen to have MS Visual Studio installed in different paths, the resulting
> builds are not identical. This is due to the System include paths, eg:
>
On Mon, 2 Oct 2023 14:13:23 GMT, Erik Joelsson wrote:
> > > What effect will this have on debugging?
> >
> >
> > Hi @erikj79 So this is the same as we pathmap the openjdk workspace source
> > just above, in that we only do it when ALLOW_ABSOLUTE_PATHS_IN_OUTPUT is
> > "false", which is for re
On Mon, 2 Oct 2023 14:13:23 GMT, Erik Joelsson wrote:
>>> What effect will this have on debugging?
>>
>> Hi @erikj79
>> So this is the same as we pathmap the openjdk workspace source just above,
>> in that we only do it when ALLOW_ABSOLUTE_PATHS_IN_OUTPUT is "false", which
>> is for release b
On Mon, 2 Oct 2023 14:20:12 GMT, Andrew Leonard wrote:
> > > What effect will this have on debugging?
> >
> >
> > Hi @erikj79 So this is the same as we pathmap the openjdk workspace source
> > just above, in that we only do it when ALLOW_ABSOLUTE_PATHS_IN_OUT
On Thu, 27 Mar 2025 02:21:30 GMT, SendaoYan wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Force use of lld when build os is not macosx
>
> make/autoconf/toolchain.m4 line 625:
>
>> 623: # Force use of lld, sinc
Hi,
I’m looking for help on resolving this bug please
(https://bugs.openjdk.org/browse/JDK-8363942), that we see building Eclipse
Temurin, whereby we build the “exploded image(default)” target, then externally
“sign” the binaries, then “touch” the targets using “make -t” so they don’t get
re-
56 matches
Mail list logo
