Somewhat perplexed by the error messages from the ...

# kotlin-native

[napperley]

Somewhat perplexed by the error messages from the Kotlin Native compiler when trying to build a KLib that targets linuxArm32Hfp. Below are the errors:

e: /home/napperley/repos/gui_vista/guivista-core/src/linuxX64Main/kotlin/org/guiVista/core/gobject_utils.kt: (37, 12): Type mismatch: inferred type is gulong /* = UInt */ but ULong was expected
e: /home/napperley/repos/gui_vista/guivista-core/src/linuxX64Main/kotlin/org/guiVista/core/gobject_utils.kt: (52, 38): Type mismatch: inferred type is ULong but gulong /* = UInt */ was expected

Appears as though these are the only compile errors. Seem to be close to building the library for the linuxArm32Hfp target. Are there some subtle differences with data types between arm32hf and x64 I should be aware of with Kotlin Native?

[napperley]

Signature of g_signal_connect_data function with the Arm v7 version:

GLIB_AVAILABLE_IN_ALL
gulong	 g_signal_connect_data		      (gpointer		  instance,
					       const gchar	 *detailed_signal,
					       GCallback	  c_handler,
					       gpointer		  data,
					       GClosureNotify	  destroy_data,
					       GConnectFlags	  connect_flags);

[napperley]

Identical signature with the x64 version:

GLIB_AVAILABLE_IN_ALL
gulong	 g_signal_connect_data(gpointer	instance,
					       const gchar	 *detailed_signal,
					       GCallback	  c_handler,
					       gpointer		  data,
					       GClosureNotify	  destroy_data,
					       GConnectFlags	  connect_flags);

[Artyom Degtyarev [JB]]

See this thread(https://github.com/JetBrains/kotlin-native/issues/2515). Also, I got to note that unsigned long size might differ across these targets.

[Artyom Degtyarev [JB]]

Seems like the problem is that K/N compiler defines

typedef uint32_t KUInt;
typedef uint64_t KULong;

while Glib don’t go into such details.

typedef unsigned long   gulong;

So, in some cases cinterop can produce different signatures for a different targets. For now, the best of available solutions here is to provide separate source sets.

[napperley]

Guestimating that around 98% of the code for the linuxx64 target will be the same for the arm32hf target. Still will be a big pain having to duplicate code in order to have both targets working 😦.

[russhwolf]

This same thing happens in ios when mixing 32-bit and 64-bit. Eg the NSInteger type is an Int in 32-bit things and a Long in 64-bit. On some level I think you have to expect that sometimes when the architectures you’re building for differ.

[napperley]

So code sharing is out of the question when mixing CPU architectures, and C interop is involved 😢. Huge pity since both code bases are nearly identical.

[russhwolf]

You can work around it with some targeted expect/actual. In Multiplatform Settings I use this to share most of the implementation on Apple platforms. I want to use NSUserDefaults.setInteger(NSInteger, String) but NSInteger changes based on architecture. So I define helper extensions NSUserDefaults.setInt() and NSUserDefaults.setLong() and these expect/actual to different implementations depending on whether we’re 32-bit or 64-bit.

Expect declarations: https://github.com/russhwolf/multiplatform-settings/blob/master/multiplatform-settings/src/appleMain/kotlin/com/russhwolf/settings/AppleSettings.kt#L168-L171

64-bit actual: https://github.com/russhwolf/multiplatform-settings/blob/master/multiplatform-settings/src/apple64Main/kotlin/com/russhwolf/settings/AppleSettings.kt#L21-L24

32-bit actual: https://github.com/russhwolf/multiplatform-settings/blob/master/multiplatform-settings/src/apple32Main/kotlin/com/russhwolf/settings/AppleSettings.kt#L21-L24

Usage: https://github.com/russhwolf/multiplatform-settings/blob/master/multiplatform-settings/src/appleMain/kotlin/com/russhwolf/settings/AppleSettings.kt#L82-L96