subin s v
11/22/2018, 6:56 AMAntonio Gisondi
11/22/2018, 9:44 AMlinuxX64
to linuxArm32Hfp
I receive this errror Unable to find a matching configuration of org.jetbrains.kotlinx:kotlinx-coroutines-core-native:1.0.1
Matej Kormuth
11/22/2018, 9:50 PMSam
11/23/2018, 6:02 AMWorker.execute
method at all, I'm confronted with:
kotlin.native.concurrent.Worker.execute must take an unbound, non-capturing function or lambda
Jaroslav
11/23/2018, 8:33 AMNSTimeZone().initWithName(tzName = "UTC")
but get nullpointerexception:
Uncaught Kotlin exception: kotlin.NullPointerException
at 0 greeting 0x0000000103deb2e2 kfun:kotlin.Exception.<init>()kotlin.Exception + 50
at 1 greeting 0x0000000103deb212 kfun:kotlin.RuntimeException.<init>()kotlin.RuntimeException + 50
at 2 greeting 0x0000000103deb192 kfun:kotlin.NullPointerException.<init>()kotlin.NullPointerException + 50
at 3 greeting 0x0000000103dea4db ThrowNullPointerException + 59
at 4 greeting 0x0000000103dd757a kfun:org.greeting.Product.iosSpecificOperation()kotlin.String + 298
ldavin
11/23/2018, 9:58 AMdanielbahe
11/23/2018, 1:54 PMSam
11/23/2018, 3:47 PMcomponents.main {
targets = ['ios_arm64', 'ios_x64']
outputKinds = [KLIBRARY]
baseName = "kotlinmultiplatformstorage-ios"
dependencies {
cinterop("KeychainWrapper"){
packageName "com.netguru.keychainWrapper"
includeDirs {
allHeaders "./KeychainWrapper.framework/Headers"
}
linkerOpts "-F${projectDir}"
}
}
}
As the result I have the following artifacts built:
* kotlinmultiplatformstorage-common
* kotlinmultiplatformstorage-android
* kotlinmultiplatformstorage-ios
* kotlinmultiplatformstorage-ios_debug_ios_arm64
* kotlinmultiplatformstorage-ios_debug_ios_x64
Next, I’m trying to use in the sample app configured using kotlin-multiplatform
plugin with the following gradle build script:
plugins {
id 'kotlin-multiplatform' version '1.3.0'
}
kotlin {
targets {
final def iOSTarget = System.getenv('SDK_NAME')?.startsWith("iphoneos") ? presets.iosArm64 : presets.iosX64
fromPreset(presets.android, 'android')
fromPreset(presets.iosArm64, 'ios') {
compilations.main.outputKinds('FRAMEWORK')
}
}
configurations {
compileClasspath
}
task packForXCode(type: Sync) {
final File frameworkDir = new File(buildDir, "xcode-frameworks")
final String mode = System.getenv('CONFIGURATION')?.toUpperCase() ?: 'DEBUG'
inputs.property "mode", mode
dependsOn kotlin.targets.ios.compilations.main.linkTaskName("FRAMEWORK", mode)
from { kotlin.targets.ios.compilations.main.getBinary("FRAMEWORK", mode).parentFile }
into frameworkDir
doLast {
new File(frameworkDir, 'gradlew').with {
text = "#!/bin/bash\nexport 'JAVA_HOME=${System.getProperty("java.home")}'\ncd '${rootProject.rootDir}'\n./gradlew \$@\n"
setExecutable(true)
}
}
}
}
tasks.build.dependsOn packForXCode
When building sampleapp project I’m having the following error thrown:
Undefined symbols for architecture arm64:
"_OBJC_CLASS_$_Keychain", referenced from:
objc-class-ref in combined.o
ld: symbol(s) not found for architecture arm64
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld invocation reported errors
Do you have any idea what can possibly be wrong with this config?pajatopmr
11/23/2018, 4:08 PMalec
11/25/2018, 3:44 AM.framework
file? I used to do this in the old dsl:
sourceSets {
main {
component {
baseName.set("MultiPlatformProject") // Changes the name of the output .framework file
target 'ios_arm64', 'ios_x64'
outputKinds = [FRAMEWORK]
}
}
}
but unsure if there is an equivalent in the new multiplatform dslckchen
11/26/2018, 8:12 AMjava.io.File
, right? We have to use functions such as fopen() to deal with files. Is it possible that in the future there is a kotlin.io.File
so no porting is needed?Sabrina Namur
11/26/2018, 8:20 AMDaniele B
11/26/2018, 9:19 AMSangeet
11/26/2018, 11:18 AMgalex
11/26/2018, 1:27 PMgalex
11/26/2018, 3:35 PMkpgalligan
11/26/2018, 7:52 PMyoavst
11/26/2018, 8:26 PMyuya_horita
11/27/2018, 2:11 AMSam
11/27/2018, 9:01 AMlanguage = Objective-C
headers = Keychain.h KeychainQuery.h KeychainWrapper.h
compilerOpts = -framework keychainwrapper
linkerOpts = -F/path/ -framework keychainwrapper
excludeDependentModules = true
build.gradle cinterop dependency declaration:
dependencies {
cinterop("KeychainWrapper"){
packageName "com.company.keychainWrapper"
includeDirs {
allHeaders "./KeychainWrapper.framework/Headers"
}
linkerOpts "-F${projectDir}"
compilerOpts "-F${projectDir}"
}
}
Problem:
After linking Objective-C framework generated for both architectures (x86_64 and arm64) cinterop is letting us to use only the first linked one, so if the x86_64 is the first listed in the build settings - it will work only for that architecture.
Effect:
I can use the framework on simulator only when using it in my iOS project. The project doesn’t build for the real device
Do you have an idea how this can be fixed? (xcode log in comment)JoakimForslund
11/27/2018, 12:52 PMprintf("Event: %s Value: %s ", event, value);
in a cinterop *.def file it does not seem to be sent to the stream output, is there anyway to make it show up the same way as println(..) does from commonCode ?elect
11/27/2018, 2:38 PMelect
11/27/2018, 2:48 PMgradle build
in cliJamie Lynch
11/27/2018, 7:34 PMmsink
11/28/2018, 9:30 AMkotlin-miltiplatform
project, see sample in https://github.com/msink/hello-libui
IDEA/CLion can be used for development.
Update: now on jcenter()
, sample updated.msink
11/28/2018, 5:09 PMRequest to include the package '/msink/kotlin-native/libui' in 'jcenter'
Hi,
We can only approve one path for a single package.
Please let us know which path prefix you would like to include.
Thanks,
JFrog Support
Yes, it is multiplatform package, really 3 separate packages for Linux/Windows/Mac...
Don't know what they want from me.Carl Hickman
11/28/2018, 7:04 PMtylerwilson
11/28/2018, 7:55 PMLanderl Young
11/29/2018, 7:29 AMstruct TypeInfo {
const TypeInfo* typeInfo_;
ClassNameHash name_;
int32_t instanceSize_;
const TypeInfo* superType_;
const int32_t* objOffsets_;
int32_t objOffsetsCount_;
const TypeInfo* const* implementedInterfaces_;
int32_t implementedInterfacesCount_;
const MethodTableRecord* openMethods_;
uint32_t openMethodsCount_;
const FieldTableRecord* fields_;
int32_t fieldsCount_;
ObjHeader* packageName_;
ObjHeader* relativeName_;
int32_t flags_;
const ExtendedTypeInfo* extendedInfo_;
};
So, which of them are related to reflection, which are not.
AFAIK:
1. supreType_
and implementedInterfaces_
are useful for runtime type cast check.
2. vtable
(not listed but comes after the TypeInfo struct) is useful for virtual methods calling.
3. openMethods_
is useful for interface method calling.
But some of the rest fields like packageName_
, relativeName_
, name_
, instanceSize_
, objOffsets_
, fields_
, etc. seem to be reflection related? Should they be moved into ExtendedTypeInfo
so them can be omitted when reflection is disabled?
May I get your help @olonho ? Thanks.😀yuya_horita
11/29/2018, 9:41 AMPLEASE NOTE THAT THIS ANNOTATION MAY GO AWAY IN UPCOMING RELEASES.
in https://github.com/JetBrains/kotlin-native/blob/c1a41c9dc4c69d008da0c5a83ace00f63b84dec4/runtime/src/main/kotlin/kotlin/native/Annotations.kt#L47yuya_horita
11/29/2018, 9:41 AMPLEASE NOTE THAT THIS ANNOTATION MAY GO AWAY IN UPCOMING RELEASES.
in https://github.com/JetBrains/kotlin-native/blob/c1a41c9dc4c69d008da0c5a83ace00f63b84dec4/runtime/src/main/kotlin/kotlin/native/Annotations.kt#L47Denis Shurygin
11/30/2018, 11:30 AMyuya_horita
11/30/2018, 3:09 PM