My gradle build have been failing with this error (on 1.3.40) ``` Execution failed for task ':client...

# kotlin-native

[Lulu]

My gradle build have been failing with this error (on 1.3.40)

Execution failed for task ':client:linkDebugTestLinuxX64'.
> Process 'command '/opt/java/openjdk/bin/java'' finished with non-zero exit value 1

Does anyone have an idea what that mean? Debugging wasn't that helpful.

[drieks]

hi, try ./gradlew --info <your options> or ./gradlew --stacktrace <your options>

[Lulu]

Hi Dennis, I tried those. I also ran the command above independently, it was failing because of this:

Error: Could not find or load main class Runtime
Caused by: java.lang.ClassNotFoundException: Runtime

[drieks]

is this java.lang.Runtime?

[drieks]

or is Runtime your class?

[drieks]

did you try clean first?

[Lulu]

It is used by ./gradlew build

[Lulu]

The full command is here https://pastebin.com/whurAFVi

[drieks]

maybe it is /home/lelouch/.konan/kotlin-native-linux-1.3/konan/lib/Runtime.jar, but I'm not sure..

[Lulu]

Is there anyway to debug this properly? It seems an internal thing in konan

[drieks]

I don't know.. just try rm -rf ~/.konan 🙂

[Lulu]

Will do

[Lulu]

It downloaded the compiler again, but it's still failing

> Task :client:linkDebugTestLinuxX64
e: Unable to compile C bridges

> Task :client:linkDebugTestLinuxX64 FAILED

> Task :samples:ping-native:linkDebugExecutableLinuxX64
e: Unable to compile C bridges

> Task :samples:ping-native:linkDebugExecutableLinuxX64 FAILED

FAILURE: Build completed with 2 failures.

[serebit]

It's failing on every machine that doesn't have Solus installed, weirdly enough. It succeeds on a base Solus install with curl-devel and openjdk-8 installed, but fails on Ubuntu, Debian, Arch, and Alpine.

[napperley]

Did you try Konan with Linux Mint?

[napperley]

See what happens when Konan is used with OpenJDK 11 (currently the latest LTS release). OpenJDK 12 isn't a LTS release which might explain why there are issues occurring.

[serebit]

That was our thought, but it works on OpenJDK 8 and 11 on Solus, doesn't work on OpenJDK 11 on Ubuntu or Alpine

[serebit]

I'll give Mint a try after testing Suse Tumbleweed

[napperley]

Is this on a desktop or in a Docker container?

[serebit]

We've tried:
- Solus desktop
- Solus VM
- Alpine Docker container
- Ubuntu VM
- Debian Docker container
- Arch desktop x2

[serebit]

It worked on the Solus desktop and Solus VM, but not in any of the others

[napperley]

If a container is used then this Dockerfile should provide some ideas on getting Konan working, even though it is out of date: https://github.com/JetBrains/kotlin-native/blob/master/samples/weather_function/function/Dockerfile

[napperley]

For reference Konan (via Kotlin 1.3.40) works fine on Linux Mint 19.1 with Zulu JDK 11 (installed via SDK Man).

[napperley]

Have you tried running a "release" type Gradle task?

[serebit]

It's not konan itself not working, it's something far more specific

[serebit]

You can try it yourself if you'd like, the repo is https://gitlab.com/serebit/strife and the relevant branch is linux-native

[serebit]

just run build and see if it fails

[napperley]

Try running the runDebugExecutableLinux Gradle task. This task works on Kotlin 1.3.31 (except for the run part) but not on Kotlin 1.3.40 where a protocol error appears.

[Lulu]

The result is

> Task :client:compileKotlinLinuxX64 UP-TO-DATE
> Task :samples:ping-native:linkDebugExecutableLinuxX64
e: Unable to compile C bridges

> Task :samples:ping-native:linkDebugExecutableLinuxX64 FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':samples:ping-native:linkDebugExecutableLinuxX64'.
> Process 'command '/usr/lib/jvm/java-12-openjdk/bin/java'' finished with non-zero exit value 1

[napperley]

Here are the contents of the protocol error (contents truncated for brevity):

Task :cinteropNcursesLinux
e: Compilation failed: Protocol message tag had invalid wire type.

 * Source files: ncurses.kt
 * Compiler version info: Konan: 1.3 / Kotlin: 1.3.40
 * Output kind: LIBRARY

e: org.jetbrains.kotlin.protobuf.InvalidProtocolBufferException: Protocol message tag had invalid wire type.
	at org.jetbrains.kotlin.protobuf.InvalidProtocolBufferException.invalidWireType(InvalidProtocolBufferException.java:99)
	at org.jetbrains.kotlin.protobuf.CodedInputStream.skipField(CodedInputStream.java:262)
// ...

[napperley]

Do you get the infamous Kotlin Native protocol error (a serious Kotlin 1.3.40 regression)?

[napperley]

What happens if you downgrade Kotlin to 1.3.31?

[serebit]

No, we don't. If we downgrade Kotlin to 1.3.31, the project doesn't compile at all, regardless of distribution

[serebit]

If we stay on 1.3.40, we get the error Lulu just sent. Everything else succeeds, and the project compiles correctly on Solus only.

[napperley]

Really weird. Is the project available publicly via GitHub or GitLab?

[Lulu]

Yeah the link is above

[Lulu]

The exception we get is

org.gradle.process.internal.ExecException: Process 'command '/usr/lib/jvm/java-12-openjdk/bin/java'' finished with non-zero exit value 1
        at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:396)
        at org.gradle.process.internal.DefaultJavaExecAction.execute(DefaultJavaExecAction.java:38)
        at org.gradle.process.internal.DefaultExecActionFactory.javaexec(DefaultExecActionFactory.java:129)
        at org.gradle.api.internal.project.DefaultProject.javaexec(DefaultProject.java:1103)

[serebit]

This only happens on the linux-native branch of that repository, which is the branch that contains the kotlin/native implementation

[olonho]

please use JDK 8 and remove all .klib files

[olonho]

and please provide full error dump in pastebin

[serebit]

Can confirm that this also happens with JDK 8, our testing was a mix of JDKs 12, 11, and 8. Removing all klib files will be a challenge though. Should I provide the build trace with -debug -stacktrace @olonho?

[olonho]

and -i as well

[serebit]

Sure thing

[serebit]

I'll pastebin the log from a successful build on Solus, Lelouch will pastebin the log from a failed build on Arch

[serebit]

We've tested on several distributions across several configurations. The build only succeeds on Solus and Fedora, as far as we're aware. It fails on Arch, Ubuntu, Debian, OpenSUSE Tumbleweed, and Alpine. The JDK version seems to have no effect, as both JDKs 8 and 11 succeed on Solus while JDKs 8 and 12 fail on Arch.

[serebit]

The log is too long for Pastebin, can I omit --debug? @olonho

[serebit]

Failed run (OpenSUSE Tumbleweed VM, JDK 11): https://pastebin.com/BgP4SCea
Successful run (Solus, JDK 11): https://pastebin.com/uMbfQKbU
Successful run (Solus VM, JDK 8): https://pastebin.com/KqMVY2sV

Both VM runs were done in near-base QEMU/KVM installations of their respective Linux distributions. Only the packages required to clone and build the project were installed in the VM runs. The command used was ./gradlew clean build --info --stacktrace. The build cache was populated before each run.

[Artyom Degtyarev [JB]]

Hello everyone! I have built your project on OpenSUSE Tumbleweed, just a second ago, facing only one issue. It also stopped on this task, but the log was slightly different. I got to install libcurl-devel package and then got totally no issues. Please try this, and call me if it won’t work.

[serebit]

@Artyom Degtyarev [JB] The Solus VM also needed that package to be installed for the build to succeed, so it's something we've noticed, but not on SUSE. I'll see if installing the package changes anything, but I don't think it will

[serebit]

Yep, the base OpenSUSE Tumbleweed VM install still fails to compile the project with libcurl-devel installed. The log appears to be identical

[serebit]

If your SUSE installation is able to compile Strife and my SUSE installation isn't, we may have a lead

[Lulu]

Update: After commenting all test files, the build succeeds on my Arch installation, but it still fails in alpine docker image.

[Lulu]

Uncommented all test files and I can still build the branch successfully. I have no idea what has changed.

[Lulu]

The docker image still fails with e: Unable to compile C bridges

[Artyom Degtyarev [JB]]

At the moment I still can not reproduce this problem, so its causes cannot be recognised. Can you share the docker image? It would be very helpful.

[serebit]

Sure, the docker image we've been using is adoptopenjdk/openjdk11. We've tested with the alpine and debian tags, and both seem to fail in the same way.

[serebit]

If it helps, @Artyom Degtyarev [JB], we're pretty sure it isn't memory-based (as I've tested in various memory-constrained scenarios in a Solus VM, and the task refused to fail), and we're also pretty sure it isn't processor-dependent (I got both success and failure results in VMs on the same computer).

[Artyom Degtyarev [JB]]

Hello again! It looks like the problem was in the missing libtinfo.so.5 library, so the clang get stuck. This lib is unavailable on some platforms by default, so you got to install it manually.

[serebit]

I'll see if I can replicate that with our build environment, thanks for the tip!

[serebit]

@Artyom Degtyarev [JB] libtinfo.so.5 isn't available on Alpine, so I symlinked it to libncurses.so.5 instead, and got the same result.

[olonho]

same means it doesn’t work? can you just start clang binary from .konan?

[serebit]

same means it doesn't work, yes. I can give that a try

[serebit]

https://pastebin.com/pRPMiSNr Still happens when I run konanc from .konan after installing libncurses-5 and bash, and symlinking libtinfo.so.5 to libncurses.so.5.

[olonho]

what if you start clang binary manually, like ~/.konan/dependencies/clang-llvm-6.0.1-linux/bin/clang

[serebit]

What args should I pass to it?

[olonho]

no arguments, just check if it runs

[serebit]

Hmm, Artyom was right: /root/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/clang: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

[serebit]

I think my symlink might need fixing, I'll try a workaround later today

[serebit]

Seems like Solus works consistently because it symlinks libtinfo to libncurses out of the box, and few other distros do

[serebit]

So the symlink does appear to affect the build (I can force the build to fail on Solus by removing the symlink /usr/lib/libtinfo.so.5), but it's proving impossible to build in Alpine. Even copying the symlink path directly from Solus with ncurses5-widec-libs installed, the build fails. I believe updating the distribution of clang that konan downloads to 7 may fix this issue

[serebit]

FROM adoptopenjdk/openjdk11:alpine

RUN wget "<https://download.jetbrains.com/kotlin/native/clang-llvm-6.0.1-linux-x86-64.tar.gz>" && \
    tar xvzf clang*.tar.gz

RUN apk add clang ncurses5-libs ncurses5-widec-libs && \
	ln -n /usr/lib/libncursesw.so.5.9 /usr/lib/libtinfo.so.5

RUN cd clang* && \
	find /usr/lib -name "libtinfo.so.5" && \
    ./bin/clang

[serebit]

This dockerfile, despite having a symlink to libtinfo.so.5 in /usr/lib, still can't find libtinfo.so.5. On Solus, with the exact same symlink, the clang distribution runs successfully.