[native-image] Cross compilation support?

[sureshg]

Any plans to add cross-compilation feature to native-image? I know it's too early to ask for these kind of requirements since we don't even have a working Windows build. IMHO, this would be a nice feature (golang has nice support for it) to have especially if we want to build binaries for all platforms from a CI (Jenkins) machine.

https://medium.com/@chrisgseaton/i-dont-think-we-have-any-immediate-plans-for-cross-compilation-but-it-s-not-a-major-problem-to-bf789384beaa

[brainchild0]

Is this not a reasonable workaround?

@thomaswue The question has no general answer. In some cases it may be, others not. My remark directed at cases for which the answer would be negative, while acknowledging others for which it would be more optimistic.

For some open source components or platforms, you build everything in one place from scratch (or take binaries if available, but reserve the capability to build). That's just how it is.

What is worth considering is that the limitation probably will make adoption more reluctant even in border cases, due to concerns about dependence on a tool limited in broader adoptability.

We could also maybe build an Oracle cloud service for building.

Such a process is suited to projects supported by the community but still distributed as prebuilt binaries targeting major platforms. It is obviously a common case, but not the only.

[brainchild0]

Not having any useful background on the subject, I am curious to ask about feasibility for running the tool version corresponding to the target platform inside Qemu.

[rmannibucau]

We believe however that many open source (and even commercial) projects can use our GitHub Action for GraalVM to build their releases. Is this not a reasonable workaround?

No because most of this solution wouldn't be free or too expensive, plus not usable in dev - without referencing projects not using Github, including on premise projects using Gitea/Drone or alike solutions. The key point is not NOT depend on a CI to be able to build. There are cases you want the release to be signed by an employe/user and not a technical key so for these cases you need an offline solution and hopefully local only (ie not multiple VM).

[brainchild0]

There can be differences between operating systems how the JDK or third-party library dependencies are initialized and those end up snapshotted into the native image. Therefore, the problem of cross compilation for native image is more difficult to solve than cross compilation for e.g. C programs.

@thomaswue So the NI tool interrogates the memory state of the running JDK, and captures a representation for inclusion into the build target? Is the captured image specific to the application being translated, or only to the combination of kernel and machine types?

[anentropic]

What is the primary source/destination architecture you would be interested in to cross-compile, is it Linux/amd64 to Linux/aarch64? Is it possible to solve your use case with the GitHub Action workaround?

For me it would be compiling macos/aarch64 on macos/x86_64

Because GitHub actions does not have aarch64 macos runners, and for an OSS hobby project I do not want to pay for hosted Apple Silicon runners

Since all new macs are aarch64 it no longer seems worth building native images with Graal as I had been, since I can only support obsolete platforms that way

[mikehearn]

@rmannibucau

There are cases you want the release to be signed by an employe/user and not a technical key so for these cases you need an offline solution and hopefully local only (ie not multiple VM).

It's worth separating out the build from the release here. Whilst native-image can't cross-build, Conveyor can cross-package and cross-sign and is free for open source projects. So your pipeline could look like this:

• Develop on regular JVM.
• Compile with native-image using a multi-platform CI system (yes I know this is painful - I built one with home hardware to do this).
• Write a Conveyor config that pulls the artifacts from your CI outputs and then produces signed, notarized binaries and packages from whatever local hardware you have your keys on. It supports HSMs.

[rmannibucau]

@mikehearn main point is to request a solution not depending on any CI like solution which are workarounds to this issue and do not cover all build/releases cases (not merging both cases but listing both as distinct but valid).

[mikehearn]

Yes, but that may not arrive any time soon and wouldn't solve the signing or packaging aspects, you'd still need other tools for that. I mention it here as an answer to your second part, so people who want to distribute CLI or GUI tools to desktops with local signing can know where to look.

[thomaswue]

@brainchild0 The state is specific to the application being translated.

In addition to this, we are depending on the local C developer tool chain a lot, so whatever cross-compilation combination we should support also needs to be available from that tool chain.

There is also the option to build within a docker container.

So, when looking at the existing workarounds such as Docker, GitHub Actions, Conveyor and the complexity of supporting all source/target platform combinations (with 5 supported platforms that would be 25), it seems like it would not be the best prioritization of engineering effort for the project at the moment. We will look more into build server setups that we can make available. Such a scenario can have additional advantages such as faster builds.

[rmannibucau]

All the mentionned solutions are at least as bad as requiring a local stack and most are more impacting like requiring to oss the project, to pay or just to not be able to run locally. All that are blockers to a solution to this issue so please invest in cross chains more than platforms which are just the current workaround.

[brainchild0]

In addition to this, we are depending on the local C developer tool chain a lot, so whatever cross-compilation combination we should support also needs to be available from that tool chain.

Such a constraint by itself is not particularly limiting. Cross-compilation solutions have evolved quite substantially in the past decade, and the dissociation between build environment and build target is now rather common, and available without penalty.

it seems like it would not be the best prioritization of engineering effort for the project at the moment.

As previously stated, it is a matter of context and perspective . For some projects, remote builds would be a tremendous help. For others, it has no value. I think it is not completely accurate that CI is a reasonable substitute for local availability of cross-building operations, in the general case.

[NCLnclNCL]

.

[chenzhiguo]

I wonder, is there any support for cross-compilation?