riscv64 jdk11u evaluation builds are failing

[sxa]

Thank you for reporting a broken build! Please fill in the following details:

• Jenkins link to the failing log: https://ci.adoptium.net/job/build-scripts/job/jobs/job/evaluation/job/jobs/job/jdk11u/job/jdk11u-evaluation-linux-riscv64-temurin/
• Which platforms (OS+arch) are affected?: linux-riscv64
• If you look at the historic logs, does the problem appear to be specific to one machine?: No
• Link to any upstream project bug report (e.g. OpenJ9/JBS):

Ref: adoptium/infrastructure#3693 (comment)

13:29:47  Compiling 7 properties into resource bundles for jdk.jshell
13:29:47  Compiling 13 properties into resource bundles for jdk.javadoc
13:29:47  /home/jenkins/workspace/build-scripts/jobs/evaluation/jobs/jdk11u/jdk11u-evaluation-linux-riscv64-temurin/workspace/build/src/build/linux-riscv64-normal-server-release/hotspot/variant-server/support/adlc/all-ad-src.ad(0) Semantic Error: :File read error, no input read
13:29:47  
13:29:47  gmake[3]: *** [gensrc/GensrcAdlc.gmk:182: /home/jenkins/workspace/build-scripts/jobs/evaluation/jobs/jdk11u/jdk11u-evaluation-linux-riscv64-temurin/workspace/build/src/build/linux-riscv64-normal-server-release/hotspot/variant-server/support/adlc/_adlc_run.marker] Error 1
13:29:47  gmake[3]: *** Waiting for unfinished jobs....
13:29:53  gmake[2]: *** [make/Main.gmk:265: hotspot-server-gensrc] Error 2
13:29:53  gmake[2]: *** Waiting for unfinished jobs....
13:29:53  Compiling 117 files for BUILD_java.compiler.interim
13:30:06  Compiling 394 files for BUILD_jdk.compiler.interim
13:31:39  Compiling 299 files for BUILD_jdk.javadoc.interim
13:32:20  
13:32:20  ERROR: Build failed for targets 'product-images legacy-jre-image test-image static-libs-image' in configuration 'linux-riscv64-normal-server-release' (exit code 2) 
13:32:20  
13:32:20  === Output from failing command(s) repeated here ===
13:32:20  * For target hotspot_variant-server_support_adlc_adlc_run:
13:32:20  /home/jenkins/workspace/build-scripts/jobs/evaluation/jobs/jdk11u/jdk11u-evaluation-linux-riscv64-temurin/workspace/build/src/build/linux-riscv64-normal-server-release/hotspot/variant-server/support/adlc/all-ad-src.ad(0) Semantic Error: :File read error, no input read
13:32:20  
13:32:20  
13:32:20  * All command lines available in /home/jenkins/workspace/build-scripts/jobs/evaluation/jobs/jdk11u/jdk11u-evaluation-linux-riscv64-temurin/workspace/build/src/build/linux-riscv64-normal-server-release/make-support/failure-logs.
13:32:20  === End of repeated output ===

This may be related to how the tags are created. We are currently building from tags in the repository, and I suspect that these are being created only from the master branch and not picking up the fixes from the (default) riscv-port branch

Unless we can get suitable tags created with the changes from the riscv-port branch it is likely that these builds will be failing indefinitely.

Noting that @Haroon-Khel's build at https://ci.adoptium.net/job/build-scripts/job/jobs/job/evaluation/job/jobs/job/jdk11u/job/jdk11u-evaluation-linux-riscv64-temurin/40/parameters/ which did not include a tag (so will have built from the default riscv-port branch) succeeded. We have a couple of options:

• Remove this build from the pipelines (since they pass the tag through) and look at just building that one periodically on a schedule.
• Identify a mechanism for tagging something appropriate on the riscv-port branch and building that.

The first option is potentially a good initial solution to allow the builds to run through, however since it won't be explicitly from an upstream tag we probably wouldn't want to publish it alongside the others since they are not exactly at a tag.

[luhenry]

@sxa thanks for this write up.

There hasn't been a huge flurry of activity on the riscv-port-jdk11u port, but I attribute it to a lack of demand. Having Adoptium drive such demand would be a useful boost.

Unless we can get suitable tags created with the changes from the riscv-port branch it is likely that these builds will be failing indefinitely.

Is that something that would need to happen on https://github.com/openjdk/riscv-port-jdk11u/ directly? Or is there something we can do on our mirror of that repo?

Remove this build from the pipelines (since they pass the tag through)

I'm not sure what you mean by "this build".

and look at just building that one periodically on a schedule.

Would we need the tag in order to release jdk11u? And would these tag required to be done automatically?

[sxa]

@sxa thanks for this write up.

There hasn't been a huge flurry of activity on the riscv-port-jdk11u port, but I attribute it to a lack of demand. Having Adoptium drive such demand would be a useful boost.

Hard to say - I'm not sure Adoptium would particularly want to actively encourage use of what is a relatively old version, so I feel that any demand should come from the user base (also on a purely personal note I'd rather have a headful jdk21 than a jdk11 for example, although that would generate extra work at release time, but bring consistency with other Linuxes - I feel that us releasing a headful riscv64 JDKis perhaps more using that a headful s390x build ;-) )

Unless we can get suitable tags created with the changes from the riscv-port branch it is likely that these builds will be failing indefinitely.

Is that something that would need to happen on https://github.com/openjdk/riscv-port-jdk11u/ directly? Or is there something we can do on our mirror of that repo?

Either should be feasible although my preference would be to have it upstream if possible. A comparable example is the jdk8/arm32 port which is also in a separate repository. In there we get similar tags to what we have in the jdk11/riscv64 repo, but there are additional ones with names like jdk8u422-ga-aarch32-20240725 that include the arm32 specific changes. I'll not that that's not ideal either since we have to initiate the pipelines separately due to the different tag, but that would perhaps be the easier option to go for if it was possible upstream.

Remove this build from the pipelines (since they pass the tag through)

I'm not sure what you mean by "this build".

Apologies for the lack of clarity - I mean remove jdk11u/riscv64 as one of the platforms that is kicked off automatically via evaluation-openjdk11-pipeline (defined in jdk11u_evaluation.groovy when there is a new tag in the upstream openjdk repository, since the tag cannot be built on that platform.

and look at just building that one periodically on a schedule.

Would we need the tag in order to release jdk11u? And would these tag required to be done automatically?

We've built off custom tags before, so for release purposes we could manually generate a tag in the adopt repository, but if we can avoid manual steps that would be preferable but not absolutely required..

[sxa]

This is being discussed on the riscv-port-jdk11u list at https://mail.openjdk.org/pipermail/riscv-port-dev/2024-August/001396.html

[sxa]

A tag has now been created upstream similar to how the aarch32 ports are done and the _adopt version of that tag has been created automatically by the mirror scripts. I've kicked off a build with it here (SCM_REF parameter) at https://ci.adoptium.net/job/build-scripts/job/jobs/job/evaluation/job/jobs/job/jdk11u/job/jdk11u-evaluation-linux-riscv64-temurin/44/console (although the automation in the evaluation pipeline won't currently pick this up automatically in the future without additional modifications) but that has failed with:

12:45:18  checking if packaged modules are kept... yes (default)
12:45:18  configure: error: "4-riscv64-20240825" is not a valid numerical value for VERSION_BUILD
12:45:18  configure exiting with result code 1

So a bit of extra work is going to need to happen here before we can build this regularly.

[sxa]

Passes if I add -B 4 to the BUILD_ARGS in the job to override the detected value.

I suspect it's somewhere around

temurin-build/sbin/build.sh

Line 418 in 1f1cebf

buildNumber=$(echo "${openJdkVersion}" | cut -d_ -f1 | cut -f2 -d"+")

that needs to be modified with a fix similar to

temurin-build/sbin/build.sh

Line 390 in 1f1cebf

buildNumber=$(echo "${openJdkVersion}" | cut -f2 -d"-")

which is done for jdk8 to strip off the extra suffix.

[sxa]

That's interesting ... I haven't looked into it too closely by https://ci.adoptium.net/job/build-scripts/job/jobs/job/evaluation/job/jobs/job/jdk11u/job/jdk11u-evaluation-linux-riscv64-temurin/46 which was automatically kicked off yesterday seemed to get through the build despite being run from jdk-11.0.25+5_adopt and not the riscv64 specific tag.