On Mon, Sep 21, 2020 at 09:24:36PM +0100, Julian Gilbey wrote: > On Mon, Sep 21, 2020 at 07:03:08AM -0700, tony mancill wrote: > > On Mon, Sep 21, 2020 at 10:01:35AM +0100, Julian Gilbey wrote: > > > On Sun, Sep 20, 2020 at 09:59:22PM -0700, tony mancill wrote: > > > > Hi Tiago, hi Julian, > > > > [...] > > > > Julian, I applied the patch and built the package successfully, but > > > > jlink still fails with the "expected hash" error. It's (perhaps) > > > > interesting that the expected hash does differ between the patched build > > > > and the unpatched build. > > > > > > That's really bizarre. I checked running strip-nondeterminism on the > > > resulting jmods and it seemed to be OK. But if so, then I've clearly > > > overlooked something. > > > > I'm wondering if we just need more of it sprinkled about earlier in the > > build. I didn't believe it at first and so rebuilt (more than once) to > > be sure. > > Hi Tony, > > Here are a couple more thoughts on exploring this: > > * Search through the build log to check that strip-nondeterminism is > actually being called. If it's not, perhaps the patch has > accidentally not been applied.
The patch is definitely being applied and run during the build. I see output like this for each of the jmods: Executing: [strip-nondeterminism /<<PKGBUILDDIR>>/build/support/images/jmods/java.xml.jmod && /bin/mv /<<PKGBUILDDIR>>/build/support/images/jmods/java.xml.jmod /<<PKGBUILDDIR>>/build/images/jmods/java.xml.jmod] > * Run the sha256sum command (protected with a '-' in case it fails!) > at several points in the build-arch and install targets to see when > the hashes change, if at all. Good idea. I am doing that now, and also building without parallelism, since I'd like to see the build logs for a single jmod being built without those being interspersed with others. Specifically, I'd like to see the order in which the jmods are built and the hashes recorded. Somewhere along the line, we must be invoking jmod hash / --hash-modules on a jmod before strip-nondeterminism was invoked. >From the jmod manpage: > With the --hash-modules option or the jmod hash command, you can, in each > module's descriptor, record hashes > of the content of the modules that are allowed to depend upon it, thus > "tying" together these modules. This > enables a package to be exported to one or more specifically-named modules > and to no others through qualified > exports. The runtime verifies if the recorded hash of a module matches the > one resolved at run time; if not, > the runtime returns an error. One other thing I wanted to mention is what I'm using for a test case: jlink --add-modules java.desktop --output test This fails, complaining about the hash of java.xml recorded in java.base. But other invocations of jlink are successful with the patched build. For example, the following is fine: jlink --add-modules java.base --output test As does java.compiler and 32 others. So 34 are okay and 38 of them are failing. The "good" vs. "fail" modules are attached in case it sparks inspiration for someone. I will take a look at the output of the non-parallelized build in the (GMT-7) morning. So there are approximately 50/50 odds that your test case is working (hence the confusion), because the strip-determinism patch is only be causing problems for a subset of modules. Thank you for the ideas. I will keep working on it. Cheers, tony
java.base java.compiler java.desktop java.management.rmi java.naming java.prefs java.se java.security.jgss java.sql java.sql.rowset java.xml.crypto jdk.accessibility jdk.aot jdk.crypto.cryptoki jdk.editpad jdk.hotspot.agent jdk.incubator.jpackage jdk.internal.vm.compiler jdk.internal.vm.compiler.management jdk.javadoc jdk.jconsole jdk.jdeps jdk.jshell jdk.jstatd jdk.management jdk.management.agent jdk.naming.dns jdk.naming.rmi jdk.rmic jdk.scripting.nashorn.shell jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom
java.datatransfer java.instrument java.logging java.management java.net.http java.rmi java.scripting java.security.sasl java.smartcardio java.transaction.xa java.xml jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.dynalink jdk.httpserver jdk.incubator.foreign jdk.internal.ed jdk.internal.jvmstat jdk.internal.le jdk.internal.opt jdk.internal.vm.ci jdk.jartool jdk.jcmd jdk.jdi jdk.jdwp.agent jdk.jfr jdk.jlink jdk.jsobject jdk.localedata jdk.management.jfr jdk.net jdk.nio.mapmode jdk.scripting.nashorn jdk.sctp jdk.unsupported jdk.zipfs
