Re: cross-building java bindings
Hi IOhannes,
I can only give a partial answer here, but maybe it helps demystify
things a little.
On Mon, Feb 21, 2022 at 05:14:25PM +0100, IOhannes m zmölnig (Debian GNU|Linux) wrote:
> one of my packages (csound) provides java-bindings.
> for this, it B-Ds on "default-jdk".
I think there are existing packages that do successfully cross build
java bindings using JNI. None come to my mind at present though. The
gist is that it can be made to work somehow.
> Unfortunately, "default-jdk" pulls in the HOST binaries of `javac`, which of
> course doesn't work when cross-building.
We need to talk about jdk vs jre here. The jdk is somewhat like the
compiler and the jre is something like the relevant libraries. As you
figured, you need the build architecture jdk, but you also need the host
architecture jre unless I am mistaken somehow.
> i wonder: is the correct solution to B-D on "default-jdk:native", or to set
> the default-jdk's (and probably it's dependencies that actually implement
> the "Default JDK"'s) Multi-Arch field to "foreign" (or something else)?
Going Multi-Arch: foreign most likely is wrong as you probably can
interact with the jdk in an architecture-dependent way (e.g. by loading
JNI components into some component of it).
> i see that "openjdk-11-jdk-headless" (which is what "default-jdk" ultimately
> installs today) is marked "Multi-Arch: same".
>
> this probably only shows that i am still utterly confused when it comes to
> Multi-Arch hints.
Java is being packages to allow as much coinstallability as possible. So
you can actually coinstall various openjdk versions for various
versions, but the default-jdk is the component that picks a default and
since there can be only one default, it cannot be coinstallable with
itself.
> anyhow, i *think* the situtation for "default-jdk" (and "default-jre") is
> actually comparable to Python3 (which uses "Multi-Arch: allowed"; and in the
> B-Ds i use "python3:any").
> if this is correct, i figure that the solution really has to go into
> "default-jdk" and I cannot do much about the current situation.
You figure that any "Multi-Arch: allowed" can be implemented by a layer
of indirection? Consider package foo being M-A:allowed. Now you could
add a package "foo-any" being "Architecture: all" + "Multi-Arch:
foreign" + "Depends: foo". Now a dependency on "foo:any" is roughly
equal to a dependency on "foo-any". (The difference being that the
former allows satisfying the dependency using a non-native "foo", but
that's almost never what you want.)
Your comparison to Python is correct though. The Python packaging is
quite similar in this regard. When you want to cross build Python
extensions, you need to B-D on "python$something-dev:any,
libpython$something-dev" (where that $something usually is empty, a
version or "-all").
> except of course: file bug reports.
> but i would very much welcome it if somebody who actually knows what they
> talk about would do that :-)
I don't really now and have stayed away from java (except for moving it
to B-D-I where possible as josch suggested).
However, I do think that for both Python and Java the packaging looks
backwards to me. Both of them comfort a niche use case at the expense of
the standard use case: Both make it easy to depend on a non-native
compiler/interpreter while making the standard use case of cross
building hard. Contrast that to perl. We've established this magical
package "perl-xs-dev" now. You build a perl extension? You add
perl-xs-dev to Build-Depends. It takes care of pulling the build
architecture interpreter together with the hosts library. It wouldn't be
hard to mirror that for Python. An empty "python-xs-dev" package could
be "Architecture: any" + "Multi-Arch: same" + "Depends: python3-dev:any,
libpython3-dev". It's not what we've settled on now and transitioning
all Python extensions would amount to a huge cost.
Does any of this help?
Helmut
Reply to: