Coroutines are not built for arm ( targets linuxArm32Hfp and others)

[harlem88]

When I build kotlin-native project for linuxArm32Hfp receive:
Unable to find a matching configuration of org.jetbrains.kotlinx:kotlinx-coroutines-core-native:1.0.1

[Nohus]

Is there any update on this? It has been almost a year and the issue was neither addressed nor closed. I am developing a Raspberry Pi IoT project and the lack of coroutines is quite a blow.

[elizarov]

You can build your own version for linuxArm from the sources, but you'll also need to build https://github.com/Kotlin/kotlinx.atomicfu first. We'll expand the set platforms available out of the box at some point.

[qwwdfsad]

I think we will address this issue right after Kotlin 1.3.60 release (along with #1596)

[sockeqwe]

@qwwdfsad any timeline for this to be released?

[AlexanderBykin]

@elizarov
looks like a compilation quest, compilation errors appear when building kotlinx.atomicfu

e: kotlinx.atomicfu/atomicfu/src/nativeMain/kotlin/kotlinx/atomicfu/locks/Synchronized.kt: (4, 8): Unresolved reference: interop

let me repeat the question above:
any timeline for this to be released?

[elizarov]

No specific timeline at the moment.

[napperley]

It has been many months since there was an update to this issue. @elizarov - What is the current status on support for the Linux Arm targets? Why are the IOS Arm targets a higher priority than the Linux Arm targets?

[napperley]

If testing for the Linux Arm targets is a issue then there are some solutions available. With the Linux Arm based targets (not the Android ones) testing can either be done through QEMU, or on a Arm based computer (eg a SBC like a Raspberry Pi, or Beagle Bone Black for instance) via SSH. The testing method that is used will heavily depend on the software being tested. For the QEMU option the buildroot would be setup in a similar way as described in this article.

[elizarov]

The status is the same. We don't currently have the capacity in our team to support Linux ARM and no near-term priority in that direction.

[Thomas-Vos]

It would be great if the Linux arm32 target could be added. We would like to use this target for Tizen OS smart watches in our app. We are using kotlinx.coroutines but that does not appear to have the required target.

Kotlinx.serialization does have support for Linux arm targets, see the following: https://github.com/Kotlin/kotlinx.serialization/blob/fb65be2e43cd5df41ab1c8db0f456bcf57033e6f/gradle/native-targets.gradle#L95-L98

I am not sure how they are testing the Linux targets in their project.

[LouisCAD]

@Thomas-Vos Are you able to run Kotlin code on Tizen OS already? 👀

[Thomas-Vos]

@LouisCAD yes, I have Kotlin code working on physical Tizen OS watches (specifically the Galaxy Watch).

I am using the linuxArm32Hfp target. Cinterop with native Tizen libaries works too. Needed to use a workaround for soft float from here: JetBrains/kotlin-native#3350 (comment) (will be easier when Kotlin 1.4.30 is released with the new -Xoverride-konan-properties flag. However. it would be better if a new target is added for soft float). I am currently exporting a static lib and including that in Tizen Studio. The code works and I verified the Kotlin code can actually interop with Tizen code. Unfortunately, I am still waiting for the Linux targets to be added in AtomicFU, Coroutines, and Ktor, before I can actually start developing further.

The Tizen OS emulator is a bit more challenging. It is an x86 emulator. I think I would need a linuxX86 target but unfortunately that does not exist in Kotlin/Native. If you have any ideas, let me know.

[napperley]

@Thomas-Vos - The Tizen emulator is X64 (also known as amd64 in Linux), which should be covered by Kotlin Native's linuxX64 target (already supported by KotlinX Coroutines). On the Tizen website ALL downloads (for Linux, Windows, and Mac OS X) are X64 only.

[napperley]

It seems as though the Kotlin team is split on Linux support for Kotlin Native. With some major Kotlin libraries developed by JetBrains there is good Linux support (eg KotlinX Serialization), while there are other libraries that barely have Linux support (eg KotlinX Coroutines). Everywhere there is inconsistency on Kotlin Native's Linux support, this has to change! Looks like the Kotlin team is placing way too much focus on Apple platforms to the detriment of support for other platforms like Linux for example.

Would not be too surprising that there are some prominent members on the Kotlin team that are heavily for Linux support on Kotlin Native that aren't being allowed to significantly improve the situation. Must be extremely frustrating for them considering they understand the huge importance of the Linux platform from a business/technical standpoint, especially with Embedded Linux which is a large market that would easily rival the Apple platforms.

[Thomas-Vos]

@Thomas-Vos - The Tizen emulator is X64 (also known as amd64 in Linux), which should be covered by Kotlin Native's linuxX64 target (already supported by KotlinX Coroutines). On the Tizen website ALL downloads (for Linux, Windows, and Mac OS X) are X64 only.

Thanks for the details. However, when I try to create an emulator I can only select x86. See attached screenshot. I tried it on macOS and Windows. Are you sure the Tizen OS emulator is 64 bit as well?

I created an issue on YouTrack about the missing targets for Tizen OS: https://youtrack.jetbrains.com/issue/KT-43808

[clydebarrow]

Very disappointed to run into this hurdle. Any updates on when it might be addressed?

[e5l]

We also need arm targets to solve https://youtrack.jetbrains.com/issue/KTOR-872

[arkivanov]

As an alternative one can use Reaktive, it does support linuxArm32Hfp and is tested against this target.

[soywiz]

Hey folks, we are also interested in this. We want to support Raspberry Pi and Raspberry Pi Zero in KorGE so we need 32-bit and 64-bit linux versions.

Made this PR here to add those targets to atomicfu: https://github.com/Kotlin/kotlinx.atomicfu/pull/193/files

Is anything we can do to move this forward, is there any blockers like not being able to execute tests, or it is just a matter of bandwidth?

[ObsidianX]

Enabling Arm32/Arm64 is pretty simple: #2841 though based on one of the comments on the kotlinx.atomicfu issues board it sounds like it's a matter of testing and officially supporting the build, not just generating it.

[JavierSegoviaCordoba]

This is blocking kotest to use the Linux ARM target, why can't it be merged?

[dkhalanskyjb]

@JavierSegoviaCordoba please see https://youtrack.jetbrains.com/issue/KT-43996

[clydebarrow]

This is a major blocker for me. Surely it can't be too hard?

[Nohus]

2 years later, I would still love to have this resolved. I am still building Raspberry Pi electronics with Kotlin/Native and still can't use coroutines. :/

[danbrough]

kotlinx.coroutines with linuxArm64 and linuxArm32Hfp

This fork has minimal changes to allow building linuxArm64 and linuxArm32Hfp kotlin native libraries.

Binaries are available on my maven repository at:
https://h1.danbrough.org/maven

The current versions available are:

• 1.5.2-danbroid
• 1.5.2-danbroid-native-mt
• 1.6.0-RC-danbroid

With the source code at:
https://github.com/danbrough/kotlinx.coroutines
and https://github.com/danbrough/kotlinx.atomicfu

So far I've only tested the linuxArm64 binaries on a RPI3 running debian 64bit.

[clydebarrow]

Binaries are available on my maven repository

Thanks! I've just built on a mac and run on a 32 bit RPI (original version with 512MB RAM) and it works! Awesome!

For the benefit of others, here is my build.gradle.kts with configs for host (macOS) and Pi targets:

plugins {
    kotlin("multiplatform") version "1.6.10"
    kotlin("plugin.serialization") version "1.6.10"
}

repositories {
    mavenCentral()
    maven(url = "https://h1.danbrough.org/maven/")
}

kotlin {
    val hostOs = System.getProperty("os.name")
    val isMingwX64 = hostOs.startsWith("Windows")
    val hostTarget = when {
        hostOs == "Mac OS X" -> macosX64("host")
        hostOs == "Linux" -> linuxX64("host")
        isMingwX64 -> mingwX64("host")
        else -> throw GradleException("Host OS is not supported in Kotlin/Native.")
    }

    hostTarget.apply {
        binaries {
            executable {
                entryPoint = "main"
            }
        }
    }
    linuxArm32Hfp("pi").apply {
        binaries {
            executable {
                entryPoint = "main"
            }
        }
    }
    sourceSets {
        commonMain {
            dependencies {
                implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.3.2")
            }
        }
        val hostMain by getting {
            dependencies {
                implementation("org.jetbrains.kotlinx:kotlinx-datetime:0.3.2")
                implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.0")
            }
        }
        val piMain by getting {
            dependencies {
                implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-linuxarm32hfp:1.6.0-danbroid")
                implementation("org.jetbrains.kotlinx:kotlinx-datetime-linuxarm32hfp:0.3.1-danbroid")
            }
        }
    }
}

[danbrough]

I've setup a github repo at https://github.com/danbrough/kotlinxtras/ as a hub for tweaked packages for linuxArm32Hfp,linuxArm64 and the android native targets.
It would be useful to anyone who wants to use kotlin native coroutines, okio, atomicfu, datetime, serialization, ktor with curl or who just needs curl or openssl support in their kotlin native app.
Those are all working and there are precompiled packages at:
https://s01.oss.sonatype.org/content/groups/staging/org/danbrough/ for pre-releases before they are published to: https://repo.maven.apache.org/maven2/org/danbrough/

[nicolasfara]

Kotlin 1.8.0 was released two days ago and still no support for Linux ARM, any news about those platforms?

[audkar]

@qwwdfsad There is no support for linuxArm32Hfp. I think this issue was marked as done by mistake. May be very confusing if some people come to this GH issue and see it as `complete'.
Would be good to keep it open if there is a glimmer of hope to implement this in a future. Or explicitly close it with a resolution that KT will never support this Linux architecture.

[dkhalanskyjb]

See https://kotlinlang.org/docs/native-target-support.html#deprecated-targets

[Nohus]

Yes, this should be closed as it won't be done, not marked as complete.

[luca992]

linuxArm64 was added 🙌