eclipse-platform
Updated the code related to LoongArch and added the necessary so files.
When I tried to build the Eclipse platform on the LoongArch platform, I found that the relevant code was too outdated. Therefore, I made some modifications, including modifying the code and compiling the necessary so files. If this is appropriate, I will submit modifications to other submodules of the Eclipse platform (eclipse.platform.ui, equinox, etc.) in the next few days.
Unfortunately, we can not accept the binaries submitted as they will get out of sync with java parts whenever the next change is. What is needed is getting longarch builder in the EF infrastructure which the project can use to rebuild native parts whenever needed.
Unfortunately, we can not accept the binaries submitted as they will get out of sync with java parts whenever the next change is. What is needed is getting longarch builder in the EF infrastructure which the project can use to rebuild native parts whenever needed.
Thanks for your reply!
Could you tell me in which form I can provide the loongarch builder to EF? Is it acceptable to use methods other than physical machines (such as qemu)?
Thanks again :)
Should these natives not already be build automatically? @HannesWell ?
@tianxu1997 I think the best is to look how it is done for other platforms and check if cross compile is possible.
Should these natives not already be build automatically? @HannesWell ?
@tianxu1997 I think the best is to look how it is done for other platforms and check if cross compile is possible.
thank you! I tried but didn't found any evidence of cross-compilation, maybe I missed something？ FYI, here is the link of ci workflow https://ci.eclipse.org/releng/view/SWT%20Natives/job/gtk_linux_aarch64/131/console
@fredg02 should be able to answer the question about providing a machine.
Unfortunately, I need to quote the first paragraphs of https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4276#note_1752405:
thank you for your willingness to support the SWT project. Your generosity and eagerness to contribute are greatly appreciated. However, we must decline the offer to connect external machines to our production systems. As much as we value community contributions, the security of our projects and infrastructure is our top priority. Connecting an external machine, regardless of intent, poses significant security risks. This situation would not be very different from connecting a USB stick found in a coffee shop to a company laptop—a practice fraught with potential security vulnerabilities.
@tianxu1997 there is no cross compiling yet I'm aware of it.... but you can look what maschine / architectures we have and then see if any of them suitable for crosscompiling/QEMU
What about having such machine (if sponsored by someone)? While cross compiling may work for producing binaries, what should we do to at least smoke test the builds (https://ci.eclipse.org/releng/job/SmokeTests/).
@akurtakov what confuses me is that according to this we modified it last week:
https://github.com/eclipse-platform/eclipse.platform.swt/tree/master/binaries/org.eclipse.swt.gtk.linux.loongarch64
so is it actually not shipped / build / used / tested / ...?
so is it actually not shipped / build / used / tested / ...?
Exactly. Just the project exists in git at the moment.
What about having such machine (if sponsored by someone)? While cross compiling may work for producing binaries, what should we do to at least smoke test the builds (https://ci.eclipse.org/releng/job/SmokeTests/).
Agree on that. We should do that like it is currently done for Windows on Arm in https://github.com/eclipse-platform/eclipse.platform.swt/pull/1045.
I also want to create a link to https://github.com/eclipse-platform/eclipse.platform.swt/discussions/175#discussioncomment-8846617 since this would not be necessary, if we would use the FFM-API for the native access.
Cross-compiling or using QEMU is probably best.
Great, I'll try QEMU, thanks for your reply:)
What about having such machine (if sponsored by someone)? While cross compiling may work for producing binaries, what should we do to at least smoke test the builds (https://ci.eclipse.org/releng/job/SmokeTests/).
Sorry about this, I'm not sure if we can provide such machine yet
Cross-compiling or using QEMU is probably best.
I try to build LoongArch64 binaries on X86 using cross-compilation.
Toolchain url: https://github.com/sunhaiyong1978/CLFS-for-LoongArch/releases/download/8.0/loongarch64-clfs-8.0-cross-tools-gcc-full.tar.xz , and this link is on this page: https://github.com/sunhaiyong1978/CLFS-for-LoongArch
After preparing the cross-compilation toolchain, I specify the values of MODEL, SWT_JAVA_HOME, and CC to compile LoongArch64 binaries on x86. And it works.
Is this solution acceptable? @akurtakov @fredg02 @HannesWell @laeubi