https://kotlinlang.org logo
Title
f

felislynx

01/26/2021, 9:52 AM
Hi, i would like to ask is there any plan at all (and if any, some roadmap for it) to support ARM architecture? My company want's to migrate old JavaFX application that runs on RaspberryPi to something more modern and currently we are divided between Flutter and QT. We would love to use Jetpack Compose since most of us know Kotlin and play with compose for some time 🙂
a

altavir

01/26/2021, 10:25 AM
Does your hardware have a JVM implementation?
f

felislynx

01/26/2021, 10:27 AM
Yes. It is latest Raspberry Pi OS on RPI 3b+. Application is written in kotlin + JavaFX (tornadoFx)
a

altavir

01/26/2021, 10:28 AM
Then compose desktop should work out of the box. It does not rely on things outside JVM.
Thr problems above are about signing the distribution for IOS, not about the programm itself.
f

felislynx

01/26/2021, 10:32 AM
i've got AWT-EventQueue-0 java.lang.Error : Unknown arch arm
i've tried by opening new project from wizard, added button and run on rpi
kotlin("jvm) version 1.4.21
o

olonho

01/26/2021, 10:33 AM
one has to compile Skiko (https://github.com/JetBrains/skiko/) for Linux ARM. Note that macOS ARM is already supported.
f

felislynx

01/26/2021, 10:34 AM
@olonho Ok, mixed input, @altavir wrote that it should work o_O
😂 1
🇳🇴 1
a

altavir

01/26/2021, 10:34 AM
I forgot that that skiko has some native dependenices.
f

felislynx

01/26/2021, 10:35 AM
Ok i understand, my question is: is this planned and if so, when there might be first pre-alpha or something
I'm not that good with c/c++ to compile this by myself 😉
and as i said, i'm willing to wait for even alpha stage to migrate app rather than using QT/Flutter or worse: Electron/React Native 😄
d

Dominaezzz

01/26/2021, 11:55 AM
a

altavir

01/26/2021, 11:56 AM
Based on the userpic he is the author of the issue 🙂
d

Dominaezzz

01/26/2021, 11:57 AM
Ooh, I just noticed. 😅😂
😄 3
I thought it looked weirdly familiar.
f

felislynx

01/26/2021, 12:03 PM
Yeah, but i though that i'll ask here just to be able to schedule work on migration from javafx. I really dont want to do it more than once :). Compose is best solution if will be available on rpi. I can put things on hold for few months or if there are no plans for upcoming months, probably qt...
j

jim

01/26/2021, 3:39 PM
@felislynx We don't officially talk about future plans nor commit to dates. That said, there have been a bunch of people requesting RaspberryPi support, so I would speculate that it would happen eventually, sooner or later. In the mean time, as @olonho mentioned, compiling skia/skiko is going to be the best way to unblock yourself. I would also recommend checking out this thread: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1610493565497900 - and I would recommend that you be super nice to to @Aru and become best friends with him, as he may have some tips and be able to help you out. As always, community contributions are welcomed.
👍 2
a

Aru

01/27/2021, 9:20 PM
Alright, here's where I'm at. I tried building Skia in two different ways and I was successful in one of them. • I built it by disabling building most of the dependencies and making it use the system dependency. For ex,
skia_use_system_libjpeg_turbo=true
. This went fine. But I was using BitBake from the Yocto build system to achieve this, and so, I cannot raise a PR for this way of building. • I tried to install a cross-compiler in Ubuntu docker image and use the scripts from
skia-build
to build it. I'm getting the below error and I cannot get past it. This looks from
libjpeg-turbo
. I cannot include the native dependency for libjpeg-tyrbo because it was cross compilation.
FAILED: obj/third_party/externals/libjpeg-turbo/simd/arm/common/libjpeg.jidctfst-neon.o 
aarch64-linux-gnu-gcc -MD -MF obj/third_party/externals/libjpeg-turbo/simd/arm/common/libjpeg.jidctfst-neon.o.d -DTURBO_FOR_WINDOWS -DC_ARITH_CODING_SUPPORTED=1 -DD_ARITH_CODING_SUPPORTED=1 -DUSE_CLZ_INTRINSIC -DNDEBUG  -w -Wno-attributes -fstrict-aliasing -fPIC -fvisibility=hidden -O3 -fdata-sections -ffunction-sections -Wno-sign-conversion -Wno-unused-parameter -march=armv8-a -O3 -isystem /src/skia/third_party/libjpeg-turbo -isystem /src/skia/third_party/externals/libjpeg-turbo  -c ../../third_party/externals/libjpeg-turbo/simd/arm/common/jidctfst-neon.c -o obj/third_party/externals/libjpeg-turbo/simd/arm/common/libjpeg.jidctfst-neon.o
../../third_party/externals/libjpeg-turbo/simd/arm/common/jidctfst-neon.c: In function 'jsimd_idct_ifast_neon':
../../third_party/externals/libjpeg-turbo/simd/arm/common/jidctfst-neon.c:87:28: error: incompatible types when initializing type 'int64_t' {aka 'long int'} using type 'int64x1_t'
   87 |   int64_t left_ac_bitmap = vreinterpret_s64_s16(vget_low_s16(bitmap));
      |                            ^~~~~~~~~~~~~~~~~~~~
I was proceeding with compilation of
skiko
inside the Yocto build system. But Skiko uses Gradle to compile the C++ code and do linking with Skia. Gradle does not support external toolchains other than
gcc
in Linux. The cross-compiler I wanna use is
aarch64-fslc-linux-gcc
. I'm trying to extend the
AbstractGccCompatibleToolChain
in Gradle to use a new toolchain but i've been unsuccessful so far.
f

felislynx

03/25/2021, 10:37 AM
@Aru do you have any progress on arm build?
a

Aru

03/25/2021, 1:36 PM
I tried compiling the C, C++ stuff with the native compiler with CMake separately and modified the gradle build to bind it with Skiko. It all compiled fine but there were some Undefined symbol errors while I run it in the embedded board. I couldn't get it to work properly and our deadline to finalize a UI framework/research was coming to an end. We gave up and decided to go with JavaFX. I'd have loved for compose to work.
😢 1
f

felislynx

03/26/2021, 6:23 AM
Maybe it is worth to share github link to your work and maybe someone with time and knowledge might push it further. My knowledge from c++ is quite limited so i can't help. I would love to see compose on RPI since JavaFX is... horror to work with 😄