-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b18
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8287514 | 17.0.4 | Andrew Leonard | P4 | Resolved | Fixed | b05 |
When building openjdk from different users or different workspace folders, the jdk binary is not always reproducible/deterministic.
There are several reasons for this from my investigations:
- Different build users causes src.zip difference due to optional extended extra zip info containing the UID/GID
- When debug symbols are generated the full workspace path gets embedded into the stripped debug info, resulting in debug symbol difference, which then causes jdk .so library difference due to the debug info CRC value being different
- hotspot ADLC library does not currently use the -fmacro-prefix-map option, so __FILE__ macros contain full workspace paths
- when generating external debug symbols the hotspot MASM files debug info entries contain full workspace paths, I believe because the debug filename mapping options don't apply to MASM
- gcc symbol random name generation is not deterministically seeded, thus it is not guaranteed to generate the same random symbol names, eg._AFTZ8_GetFileNameMethod
There are several reasons for this from my investigations:
- Different build users causes src.zip difference due to optional extended extra zip info containing the UID/GID
- When debug symbols are generated the full workspace path gets embedded into the stripped debug info, resulting in debug symbol difference, which then causes jdk .so library difference due to the debug info CRC value being different
- hotspot ADLC library does not currently use the -fmacro-prefix-map option, so __FILE__ macros contain full workspace paths
- when generating external debug symbols the hotspot MASM files debug info entries contain full workspace paths, I believe because the debug filename mapping options don't apply to MASM
- gcc symbol random name generation is not deterministically seeded, thus it is not guaranteed to generate the same random symbol names, eg._AFTZ8_GetFileNameMethod
- backported by
-
JDK-8287514 Building from different users/workspace is not always deterministic
- Resolved
- relates to
-
JDK-8284661 Reproducible assembly builds without relative linking
- Resolved
- links to
-
Commit openjdk/jdk17u-dev/3e42e258
-
Commit openjdk/jdk/4451257b
-
Review openjdk/jdk17u-dev/415
-
Review openjdk/jdk/8124
(1 links to)