It is not currently possible to build programs successfully for non amd64 architectures (such as aarch64/arm64). This is due to data type assumptions in implemented LibreOfficeKit registration callbacks. Those assumptions are not true for all CPU architectures.
For amd64, register_callback<F: FnMut(i32, *const i8) works just fine (tested with Ubuntu, Debian, Alpine)
For aarch64, a compilation error is generated for the underlying "shim" (extern C) that wants a u8 instead of an i8 parameter
My goal is to begin shipping multi-arch container images for my application (starting with arm64 support).
Proposed changes and impacts
Proposed change
Update the LibreOfficeKitCallback handler signature
The rust compiler will automatically determine what c_int and c_char mean on either amd64 or aarch64.
Impact
Technically there are no user visible changes, unless developers were explicitly manipulating the callback parameters. The callback parameters themselves are not really useful at this time (random ID and random "garbage text" upon subsequent application runs).
Verifying the changes
Existing documentation tests should still be pass
I've tested successfully compilation of my app that leverages libreoffice-rs. I don't own an arm64 computer and sadly arm64 builds are very slow from amd64 machines ( qemu-user-static + podman -> all of that inside a QEMU Ubuntu virtual machine which adds yet another layer). qemu-user-static feels a bit buggy sometimes: hanging and slow to emulate arm64.
Overview
It is not currently possible to build programs successfully for non
amd64
architectures (such asaarch64/arm64
). This is due to data type assumptions in implemented LibreOfficeKit registration callbacks. Those assumptions are not true for all CPU architectures.amd64
,register_callback<F: FnMut(i32, *const i8)
works just fine (tested with Ubuntu, Debian, Alpine)aarch64
, a compilation error is generated for the underlying "shim" (extern C
) that wants au8
instead of ani8
parameterMy goal is to begin shipping multi-arch container images for my application (starting with
arm64
support).Proposed changes and impacts
Proposed change
Update the
LibreOfficeKitCallback
handler signatureregister_callback<F: FnMut(i32, *const i8)
===>register_callback<F: FnMut(std::os::raw::c_int, *const std::os::raw::c_char)
The rust compiler will automatically determine what
c_int
andc_char
mean on eitheramd64
oraarch64
.Impact
Technically there are no user visible changes, unless developers were explicitly manipulating the callback parameters. The callback parameters themselves are not really useful at this time (random ID and random "garbage text" upon subsequent application runs).
Verifying the changes
arm64
computer and sadlyarm64
builds are very slow fromamd64
machines ( qemu-user-static +podman
-> all of that inside a QEMU Ubuntu virtual machine which adds yet another layer).qemu-user-static
feels a bit buggy sometimes: hanging and slow to emulatearm64
.