On Mon, 19 Oct 2026 13:46:19 GMT, Matthew Donovan <[email protected]> wrote:
>> yaqsun has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> 8394613: update Platform.isLinux()
>
> test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java line 146:
>
>> 144: String dir;
>> 145: try {
>> 146: dir = ProcessTools.executeCommand(opensslPath, "info",
>> "-modulesdir")
>
> The `info -modulesdir` command uses a build-time value:
>
>
> INSTALLTOP=/foo/bar/build
> LIBDIR=lib
> libdir=$(INSTALLTOP)/$(LIBDIR)
> MODULESDIR=$(libdir)/ossl-modules
>
>
> The issue I am seeing is that the downloaded bundle was built and "installed"
> to one directory (maybe a completely different computer) and then downloaded
> to a tmp directory location on a test machine. So the `info -modulesdir`
> command returns a path, however it may not be a path that exists on the
> computer that is executing the test.
>
> I don't know what a good solution to this would be. It's a little naive but
> maybe making one check for the existence of
> `<openssl>/bin/../lib{64}/ossl-modules` before trying the `info` command?
Good catch. You're right that `openssl info -modulesdir` reports the
build-time modulesdir, which is stale for the downloaded bundle (built
on a different machine).
I've updated getProviderPath to first look for the modules directory
relative to the openssl binary (<openssl>/bin/../lib/ossl-modules and
<openssl>/bin/../lib64/ossl-modules), which is correct for the
relocatable bundle, and only fall back to `openssl info -modulesdir`
when that doesn't exist (to handle distro multiarch installs).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33380#discussion_r4322205257
