I’m updating from 1.3.61 to 1.3.70 and I encounter...

# kotlin-native

[ribesg]

I’m updating from 1.3.61 to 1.3.70 and I encounter an error during the linking phase linkDebugExecutableIos.
It says

e: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld invocation reported errors

but there is no logs, so I don’t see what reported errors it’s about. Is there a way to obtain more logs? Passing --debug to gradle doesn’t do anything as I guess the error is in the call to konanc

[ribesg]

Are there arguments you can pass to konanc to get logs?

[Elena Lepilkina]

Printing of linker error should be fixed in 1.3.71
To get an error with 1.3.70 you should get konanc arguments from gradle log (use ./gradlew -i ...) anf run this konanc command line from terminal.

[ribesg]

Thanks @Elena Lepilkina, I now see the warnings I always see (conflicting ids etc) but there is still no error. When ran from a terminal, the process just seem to quit

[Elena Lepilkina]

Are you sure that you use the right konan command? Because there are several commands in log

[ribesg]

I’m using the one printed directly above e: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld invocation reported errors

[Elena Lepilkina]

That is very strange. Could you share somehow your project?

[ribesg]

No that’s not possible

[ribesg]

Wait, when I run echo $? after running the command it prints 0

[ribesg]

So running the command in the terminal does work

[ribesg]

That’s why it’s not printing errors

[Elena Lepilkina]

So it's wrong command line, could you share you log at least?

[ribesg]

Here’s what I ran in the terminal and the output

Sans titre

[ribesg]

(The conflicting ids warning has been here forever and never was a problem)

[ribesg]

Here’s what I see in XCode logs

[ribesg]

The command I ran is copied from the line with “more” at the end

[Elena Lepilkina]

It looks very strange, but if you got zero exit code it should produce executable. Is executable built or not?

[Elena Lepilkina]

Also if separate command from terminal works properly, could you please check

./gradlew --stop
./gradlew -Pkotlin.native.disableCompilerDaemon=true <your task and options>

[ribesg]

@Elena Lepilkina using that I’m now able to see the linker logs in XCode, thanks 🙂

[ribesg]

So something changed and pod frameworks got moved somehow I just need to adapt my script to the new location
Well actually the directory exists and contains the framework so that’s weird

[ribesg]

Ok I changed -F"<path>" to -F<path> and it now seem to work again. Hopefully I never get any space in this path though 😕
Not sure what changed and why but that worked with Kotlin 1.3.61

[Elena Lepilkina]

Now this option is sent via linker-option , to work with spaces you should use "-F<path>". Where is this property set?

[ribesg]

Now it’s set here

binaries.executable(listOf(buildType)) {
            baseName = "app"
            linkerOpts(
                "-F$podsBuildDir/MaterialComponents",
                "-F$carthageBuildDir"
            )
        }

[ribesg]

But if podsBuildDir contains spaces it will now fail (not in this project though).
Do you mean I should be able to use "\"-F$podsBuildDir/MaterialComponents\""?

[Elena Lepilkina]

Have you tried? It seems that now with your script there shouldn't be problems with spaces. If you have such problems, we'll fix them

[ribesg]

I just tried and it doesn’t work. But that’s not a big issue, it works without " in this specific case and I should be able to use something like .replace(" ", "\ ") if I need to. I just liked the natural solution of wrapping the argument in " better

[Elena Lepilkina]

Ok, thank you, we'll check and try to fix this.

[Elena Lepilkina]

You mentioned before that if you use in linkerOpts "-F<path>" and path contains spaces linker fails. I checked and I couldn't reproduce this behaviour linker option is passed right way with spaces. Could you share project to reproduce?

[ribesg]

Sorry but I won’t be able to do that as I am back at 1.3.61 as 1.3.70 causes too many complicated errors. I did just that "\"-F$podsBuildDir/MaterialComponents\"" and it didn’t work in my case, not sure why but I can’t share my project

[Elena Lepilkina]

No it should work properly with "-F$podsBuildDir/MaterialComponents" even with spaces. Did you check it? If no, I checked and it works

[ribesg]

linkerOpts("-F$podsBuildDir/MaterialComponents") or linkerOpts("\"-F$podsBuildDir/MaterialComponents\"")? That’s not the same thing

[ribesg]

First one works in 1.3.70, second one didn’t. That’s what I remember, can’t test it anymore

[Elena Lepilkina]

linkerOpts("-F$podsBuildDir/MaterialComponents") this is right, it works for cases with spaces also.

[Elena Lepilkina]

Ok, if you have problem with spaces in first later, please, let us know

[ribesg]

@Elena Lepilkina Hey remember this? I’m finally trying to update from 1.3.61 again, to 1.4.10 this time. And I still have this problem

[ribesg]

message has been deleted

[ribesg]

message has been deleted

[Elena Lepilkina]

Do you use linkerOpts("-F$podsBuildDir/MaterialComponents") ?

[ribesg]

Well I just checked and, no 🙂 I changed it in one place but not the other. Hopefully this works.

[ribesg]

I still had my \" somewhere

[ribesg]

Yeah it compiles. And then doesn’t run because of another new 1.4 bug, but at least this one looks fixed!