Hi Erik, Thank you for the suggestions. Yes, I agree make -t is not a great solution, and also confirm it’s odd even though the signed dylib’s timestamps are later, they get re-built.. which is probably a bug in itself. We do have a post build “Sign Verification” job as you mention, which picks up these issues, which as you suggest is very useful and necessary.
JDK-8350801 I am aware of, I discussed this with Frederic at the time as being useful. However, at the moment the difficulty is calling out from a GNU make file at one of these “exit” points to be able to call a Jenkins Job to do the signing. Unfortunately, as it stands we have to use an Eclipse Signing Jenkins job running on a secure remote node, so we have to call out to this specific Jenkins job, which is very difficult to do from a GNU make file. There is potential for us to raise an Eclipse feature request for an alternative API for us, which could be used in this environment. I am going to do some more investigation into why the dylib’s get rebuilt after signing, as if we could remove the “make -t” hack then that would be ideal. I am guessing maybe there are some “rules” that need a tweak or two. Many thanks, Andrew Sent from Outlook for Mac From: Erik Joelsson <erik.joels...@oracle.com> Date: Friday, 1 August 2025 at 19:25 To: Andrew Leonard <andrew.m.leon...@ibm.com>, build-dev@openjdk.org <build-dev@openjdk.org> Subject: [EXTERNAL] Re: JDK-8363942: Unable to make images after "make -t" This Message Is From an External Sender This message came from outside your organization. Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!99FRstz4eM87H9bZrkThkmJt0DkNhWht5MerKiEHaAwuctiV9aTiMgyU5E2Ls-V383lAHpH2hSPmTTkKwZJSQdvR4C1ktVx9W95NGg$> On 7/29/25 08:16, Andrew Leonard wrote: Hi, I’m looking for help on resolving this bug please (https://bugs.openjdk.org/browse/JDK-8363942<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-built, then build the “images”… However, after recent jdk-25 changes in idk-25+26 (I think by 8349665), this process fails. We’ve found a workaround by manually deleting the file “create-main-targets-include” before calling make images, but that doesn’t seem ideal. I've never used `make -t` so I'm not surprised it doesn't work well with the OpenJDK build. We use a lot of meta targets and tricks throughout the build, and I would expect things to behave unexpectedly when using it. I'm curious why you think you need to run `make -t` after the signing procedure? As long as none of the signing operations are resetting the modification times on the signed binaries to an earlier timestamp than the build produced, and you didn't touch any other files or source files, then rebuilding shouldn't overwrite any of the already built or signed binaries. There can of course be bugs, and historically I'm sure there have been, causing things to be rebuilt unnecessarily, so with an approach like this I would definitely recommend adding a verification step after the build that checks all binaries for signatures. Related to this, have you looked into https://bugs.openjdk.org/browse/JDK-8350801<https://bugs.openjdk.org/browse/JDK-8350801 >? It was meant to make external signing procedures easier to integrate with the build system. /Erik Many thanks Andrew Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
