Add support for Linux on riscv64

[yuzibo]

No description provided.

[yuzibo]

It can be built on riscv64 hardware with mvn clean generate-resources -Dnative=gtk.linux.riscv64

[yuzibo]

...
[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.8:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.osgi: Only qualifier changed for (org.eclipse.osgi/3.21.0.v20240910-0834). Expected to have bigger x.y.z than what is available in baseline (3.21.0.v20240717-2103) -> [Help 1]

But If I use mvn clean verify -DskipTests=true to build it, we will get the error above. It seems it was the same with CI failure.

[github-actions]

Test Results

  660 files  ±0    660 suites  ±0   1h 14m 55s ⏱️ - 3m 10s
2 201 tests ±0  2 154 ✅ ±0   47 💤 ±0  0 ❌ ±0 
6 747 runs  ±0  6 604 ✅ ±0  143 💤 ±0  0 ❌ ±0 

Results for commit c3a024e. ± Comparison against base commit 30d6266.

♻️ This comment has been updated with latest results.

[HannesWell]

I'll try to have a detailed look at this tomorrow, but from a very quick view I see that the adjustment of the Jenkins file is missing.
It looks like Temurin provides riscv64 JDKs already but I have to check JustJ:
https://adoptium.net/de/temurin/releases/?arch=riscv64&os=linux

In general the same like in #559 should be done.

[yuzibo]

Thanks.

I made one change and let us to see.

FYI, ci.eclipse.org/releng has riscv64 hardware
available also.

[yuzibo]

hmm, it was still failed.

But what confuses me is that my local error was different with our online build failure.

[yuzibo]

It looks like Temurin provides riscv64 JDKs already but I have to check JustJ: https://adoptium.net/de/temurin/releases/?arch=riscv64&os=linux

Finally I understood what mean of JustJ here. But unfortunately, there is no support for riscv64 now. But want to build JustJ on riscv64, do we first have one Eclipse SDK on riscv64 available?

It sees we can use Temurin openJdk first to build native binaries for riscv64.

[yuzibo]

I have added support riscv64 in Jenkinsfile. but it does not affect the riscv64 from build log:

[Pipeline] { (Build launcher and executable native binaries)
[Pipeline] parallel
[Pipeline] { (Branch: Matrix - PLATFORM = 'cocoa.macosx.aarch64')
[Pipeline] { (Branch: Matrix - PLATFORM = 'cocoa.macosx.x86_64')
[Pipeline] { (Branch: Matrix - PLATFORM = 'gtk.linux.aarch64')
[Pipeline] { (Branch: Matrix - PLATFORM = 'gtk.linux.ppc64le')
[Pipeline] { (Branch: Matrix - PLATFORM = 'gtk.linux.x86_64')
[Pipeline] { (Branch: Matrix - PLATFORM = 'win32.win32.aarch64')
[Pipeline] { (Branch: Matrix - PLATFORM = 'win32.win32.x86_64')

I suspect we must added Branch: Matrix - PLATFORM = 'gtk.linux.riscv64' at Jenkins backends.

[yuzibo]

I suspect we must added Branch: Matrix - PLATFORM = 'gtk.linux.riscv64' at Jenkins backends.

I am stuck in here, could you help me to have a look at this? TIA

[HannesWell]

I suspect we must added Branch: Matrix - PLATFORM = 'gtk.linux.riscv64' at Jenkins backends.

I am stuck in here, could you help me to have a look at this? TIA

That's right. Since you are not a committer on this Jenkins does not consider your changes to the pipeline file.
But I just applied them in a Replay:
https://ci.eclipse.org/releng/job/equinox/job/PR-669/8/

The build now starts but fails with:

 + sh build.sh -ws gtk -os linux -arch riscv64 install
 build.sh: 161: make: not found

I think we have to ask the infrastructure team to install make on the riscv machine.

Please move all the version bumps into a separate commit with message:

Version bumps for 4.34 stream

This way they can be identified in the history more easily.

[yuzibo]

Rebased on be2c91e

[HannesWell]

Rebased on be2c91e

Great. Thanks!

Btw. have you see my comment from the other thread?
#669 (comment)
This should solve the resolution error.

With that and once all the necessary tools in the agent are installed, I think this should be ready.

And regarding your second PR #672:
Thanks for that, but it would be fine if you add that separate commit as second commit in this PR. A separate PR is not necessary for that.

[yuzibo]

Btw. have you see my comment from the other thread? #669 (comment) This should solve the resolution error.

Thanks. I read it again carefully and now I understand what it is.:)

And regarding your second PR #672: Thanks for that, but it would be fine if you add that separate commit as second commit in this PR. A separate PR is not necessary for that.

Okay, got it. Iet me try it again.

[yuzibo]

And regarding your second PR #672: Thanks for that, but it would be fine if you add that separate commit as second commit in this PR. A separate PR is not necessary for that.

I have added this in the commit and the good news is that now the PR can be passed on CI check.:)

[yuzibo]

Rebase on 773fe39. Not sure tests/build ci failure was related with this.

[HannesWell]

Rebase on 773fe39. Not sure tests/build ci failure was related with this.

Thanks. I'll try to have a look at this this evening and all your other PRs, it's just very busy at the moment. Sorry for the delay.
But the errors are probably unrelated.

[BeckerWdf]

maybe "arm" should be in uppercase

[yuzibo]

Thanks. I'll try to have a look at this this evening and all your other PRs, it's just very busy at the moment. Sorry for the delay. But the errors are probably unrelated.

Thank you. No rush.:)

[HannesWell]

Just pushed a few adjustments to your branch, e.g. some version bumps in features are not necessary (anymore) and the version of all Linux fragments should be aligned and a few white-space fixes.

But with this change is now ready for submission.
Thanks for this.

[yuzibo]

Thank you! \o/.