under a native JVM (Azul Systems) it complains abo...

# kotlin-native

[HankG]

under a native JVM (Azul Systems) it complains about compatible dylibs, I'm guessing it's downloading the x64 ones or can't differentiat between processors with macOS?

[HankG]

What is this how to do a thread? I hate Slack's UX for threads but okay...

[HankG]

It may just be a gradle script problem

[HankG]

Can get there with some manual intervention...make XCode run under Rosetta and manually build the xcodeproj rather than using the Gradle project

[HankG]

I guess I'll check the repo if Apple Silicon is in the pipeline as a build target for Kotlin Native

[HankG]

...not seeing anything in the GitHub issue tracker or PRs...hmmm...

[Kris Wong]

I have not heard any plans from the JB team for Apple Silicon support

[Kris Wong]

but I have voiced a desire for it 🙂

[HankG]

i'm going to see how far i get

[HankG]

I mean the CPUs are already supported so...

[napperley]

Apple Silicon support is very likely to be a low priority considering that Kotlin Native's Linux support needs to be significantly improved (is long overdue especially with the Linux ARM targets), and the Linux platform has a much higher importance (especially the Embedded Linux side - https://en.wikipedia.org/wiki/Linux_on_embedded_systems ).

[HankG]

What improvements do they need for Linux? I've used it for some small Linux projects and the only thing I took great exception with was linking times.

[napperley]

Linking times are a big problem that will occur regardless of which Kotlin Native target is used. Some of the improvements that are needed on the Linux side:

1. Creation of binaries that are completely self contained (all libraries are statically linked, which also includes the standard C library, Kotlin Native runtime, and the Kotlin standard library)
2. Significantly quicker linking times with the creation of Linux binaries
3. Have a system to easily dynamically/statically link C libraries that is Linux distribution agnostic (aka not tied to a single Linux distribution)
4. Significantly quicker publishing of Kotlin Native libraries that cover one or more Linux targets
5. Documentation on the official Kotlin website that covers Linux development with Kotlin Native
6. New Kotlin Native memory model that supports both the Linux platform, and Kotlin Coroutines
7. Fix longstanding C interop issues with the bundled Linux libraries
8. Include documentation on setting up a Docker container to run a Kotlin Native program on a Linux distribution
9. Provide a tool for locating/identifying possible memory leaks in a Kotlin Native program running on a Linux target (required for Kotlin Native's new memory model)

[HankG]

Ah k.

[HankG]

Is there a document or Issue number for the Linux support updates that I could follow?

[napperley]

Would be nice if such a document existed. Kotlin Native issues that are related to Linux support are all over the place 😦 .

[HankG]

I admit to not using Kotlin Native for a big project yet but I was very pleased with it. What's one or two of the big problems that I'm probably going to come up against?

[napperley]

From the standpoint of a Kotliner that uses Kotlin Native in two Linux based commercial projects (all of them are to do with backend IoT development) these are the two big problems you are very likely to encounter:

1. Very difficult to debug Kotlin Native programs/libraries which use one or more Linux targets (often have to resort to logging/desk checking 😢)
2. Lack of proper tooling for doing remote development (includes remote debugging, and program monitoring) with Kotlin Native programs that run on one of the Linux targets

[HankG]

Good to know. Thanks!