Need to check version of ALSA being used for jdk21+ DevKit Linux builds?

[andrew-m-leonard]

A reproducible build validation check of jdk-23+21 has highlighted a miss-match in alsa version:

Binary files openjdk_build/images/jdk/lib/libjsound.so and jdk-23+21/lib/libjsound.so differ

A few recent changes have highlighted a question over version of ALSA being used?

1. making local alsa properly optional #3756 recently made jdk-11+ builds specify --with-alsa=/workspace/installedalsa, whereas before it was finding the OS system ALSA
2. Change to DevKits means a "sysroot" is being used, which means the version of ALSA is found from the DevKit sysroot and not the OS ALSA

[andrew-m-leonard]

PR #3756 probably needs correcting to only apply to jdk-8 as it was previously

Using ALSA from the sysroot of the DevKit is probably the right thing for DevKit builds, but the SBOM ALSA version is probably wrong in that case...

[judovana]

Hi. noted. Will look into it (unless it will block you in meantime).

[judovana]

Do I understand correctly, that for jdk8, you need to persists current behaviour, where the alsa tarabll si downloaded and used, but for any newr jdk, you need it to not download alsa and use system one?

In that case, I would like to invert BR \-A ", " \-\-skip-alsa behavior so it will enable download of alsa on demand. Except jdk8, where it will behave like now. wdyt?

[judovana]

To have the option different for various jdks sounds like a bad idea. So to invert it? By default system alsa will be used and only if -A is specified, then one willbe downloaded.

For jdk11+ it is as per this issue necessary, and for jdk8 it shoudl work to.

[andrew-m-leonard]

So #3756 actually fixed an issue whereby we are downloading ALSA-1.1.6 and then storing in the SBOM that ALSA-1.1.6 was used, however for jdk-11+ we were actually using the "System" ALSA which is typically 1.1.8. Now with this PR we are using the downloaded ALSA-1.1.6 that is specified in the SBOM.

The problem now is when a "DevKit" is specified, which should aid reproducible builds, but the ALSA being used is now specified --with-alsa=ALSA-1.1.6 and not the DevKit sysroot alsa, thus a DevKit does not predicate a reproducible build.

For jdk-21.0.3, the version of ALSA in the DevKit sysroot is:

• x86_64, ppc64le, s390x : ALSA-1.1.8 (from Centos 7.9)
• aarch64 : ALSA-1.1.6 (from Centos 7.6)

I propose:

1. Update DevKit builds to specify build arg --skip-alsa, so that ALSA is not downloaded, and the Devkit sysroot ALSA is then used.
2. Update the SBOM ALSA dependency checking to correctly find the version of ALSA (libjsound.so) being built into the JDK

[sxa]

I'm 50/50 on (1) in the absence of any driving issues. I suppose the question is whether there was any particular reason why we picked the one we did. And also any concerns relating to whether we can patch ALSA if required (which may be easier if we don't use packages from the C7 devkit).

But 100% we need to do (2) as a priority.

[andrew-m-leonard]

To have the option different for various jdks sounds like a bad idea. So to invert it? By default system alsa will be used and only if -A is specified, then one willbe downloaded.

For jdk11+ it is as per this issue necessary, and for jdk8 it shoudl work to.

No, I think your PR is probably correct, in that we should be either using the downloaded alsa, or the DevKit one, rather than an arbitrary "system" one, but we are discussing options...

[andrew-m-leonard]

I'm 50/50 on (1) in the absence of any driving issues. I suppose the question is whether there was any particular reason why we picked the one we did. And also any concerns relating to whether we can patch ALSA if required (which may be easier if we don't use packages from the C7 devkit).

But 100% we need to do (2) as a priority.

@sxa So using --with-alsa=ALSA-1.1.6 I suspect was setup for jdk8u originally a long time ago, and we unknowingly(maybe) moved to "System" for jdk11+. For deterministic/reproducible behaviour we should use either the DevKit sysroot alsa, or provide a specific --with-alsa=X. Using --with-alsa=X then predicates any 3rd party doing reproducible builds to have to use the exact same --with-alsa=X in addition to the DevKit.
Important note: Centos7 alsa-1.1.6 is not the same as downloaded alsa-1.1.6 !

I am thinking my preference would be to use the DevKit sysroot alsa, the patching alsa use-case is tricky as it is not part of the openjdk "source", so in that unlikely case we would have to patch the downloaded alsa headers/libs in temurin-build/ci-jenkins-pipelines prior to "make". We could equally "patch" the downloaded DevKit alsa headers/lib.

[judovana]

To have the option different for various jdks sounds like a bad idea. So to invert it? By default system alsa will be used and only if -A is specified, then one willbe downloaded.
For jdk11+ it is as per this issue necessary, and for jdk8 it shoudl work to.

No, I think your PR is probably correct, in that we should be either using the downloaded alsa, or the DevKit one, rather than an arbitrary "system" one, but we are discussing options...

Ok. Will listen (read read :) ) and learn.

From original report I understood I have to fix #3756 , becasue sbom build is consideret as chroot, and thus system alsa msut be used by default - at least for sbom build.

[andrew-m-leonard]

Need to fix issue (1.)