https://kotlinlang.org logo
#kotlin-native
Title
# kotlin-native
m

Mitchell Syer

02/22/2023, 3:23 PM
Hey, I am getting a weird error with a work project. Most of my co-workers use Macs and I use a Windows machine, and it seems like a windows specific bug. The main issue is that when I try to sync, the C interop commonizer task fails with a command too long error. More info in thread
Here is an example of my build.gradle.kts
Copy code
kotlin {
    mingwX64 {
        val main by it.compilations.getting

        val library1 by main.cinterops.creating {
            defFile = project.file("src/nativeInterop/${it.name}/library1.def")

            packageName = "library1"
            header(project.file("headers/library1/library1.h"))
            includeDirs(project.file("headers"))
        }


		val library2 by main.cinterops.creating {
			defFile = project.file("src/nativeInterop/${it.name}/library2.def")

			packageName = "library2"
			header(project.file("headers/library2/library2.h"))
			includeDirs(project.file("headers"))
		}
    }
}
Here is the specific error
Copy code
> Task :project1:commonizeCInterop FAILED


FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':project1:commonizeCInterop'.
> Process 'command 'C:\jdk-17.0.6.10-hotspot\bin\java.exe'' could not be started because the command line exceed operating system limits.

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':project1:commonizeCInterop'.
Caused by: org.gradle.process.internal.ExecException: Process 'command 'C:\jdk-17.0.6.10-hotspot\bin\java.exe'' could not be started because the command line exceed operating system limits.
Caused by: net.rubygrapefruit.platform.NativeException: Could not start 'C:\jdk-17.0.6.10-hotspot\bin\java.exe'
	at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:27)
	at net.rubygrapefruit.platform.internal.WindowsProcessLauncher.start(WindowsProcessLauncher.java:22)
Caused by: java.io.IOException: Cannot run program "C:\jdk-17.0.6.10-hotspot\bin\java.exe" (in directory "C:\project1\project1"): CreateProcess error=206, The filename or extension is too long
	at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:25)
Caused by: java.io.IOException: CreateProcess error=206, The filename or extension is too long
I've tried searching
CreateProcess error=206
in slack and google, and the only results I have found are jar building errors, not sync kotlin native c interop errors
a

Adam S

02/22/2023, 3:42 PM
is there a difference trying to build via IntelliJ or the command line? Have you tried shortening the command line? https://blog.jetbrains.com/idea/2017/10/intellij-idea-2017-3-eap-configurable-command-line-shortener-and-more/
m

Mitchell Syer

02/22/2023, 3:43 PM
I cannot use the command line shortener since the command is in the commonizeCInterop gradle task. I can build the application, only syncing causes this error.
a

Adam S

02/22/2023, 3:44 PM
what happens if you run the failing task
./gradlew commonizeCInterop
in a terminal?
if you add
--info
or
--debug
can you see the full command, why it might be so long?
m

Mitchell Syer

02/22/2023, 3:46 PM
It succeeds in terminal
e

ephemient

02/22/2023, 3:46 PM
if you move your project to a directory with a shorter name, the paths used in commands may be shorter as well
m

Mitchell Syer

02/22/2023, 3:46 PM
I moved the project and JDK to the root of the drive, and the error still happens
I don't know how to add --info or --debug to intellij gradle sync
a

Adam S

02/22/2023, 3:48 PM
sorry I didn't mean add it to the sync, I meant add it on the terminal
./gradlew commonizeCInterop --info
. Seeing the full command might give some hints.
e

ephemient

02/22/2023, 3:50 PM
hmm. I don't use Windows but I wonder if it's like Linux in that environment variables and command line length are both counted (since they both need to be transferred to the child process). perhaps running in the IDE has a larger environment and that pushes your project's commands over the edge
m

Mitchell Syer

02/22/2023, 3:53 PM
The output is huge for --info
a

Adam S

02/22/2023, 3:53 PM
haha yup, good luck
m

Mitchell Syer

02/22/2023, 4:00 PM
Could I DM this to one of you? The output contains a lot of info about my computer
a

Adam S

02/22/2023, 4:01 PM
sure, just so long as you put it in a text snippet!
m

Mitchell Syer

02/22/2023, 4:02 PM
I'll be uploading it as a file 😄
a

Adam S

02/22/2023, 4:08 PM
that is indeed an enormous command. It looks like it's putting every Windows and macOS Kotlin/Native dependency in the class path (after
-cp
)
what happens if you try checking out the project from scratch in another dir and opening it in IntelliJ?
m

Mitchell Syer

02/22/2023, 4:09 PM
Same thing, one of the first things I tried
Ok update, I disabled the MacOS target and now it works
Probably because it only needs to commonize the windows target
a

Adam S

02/22/2023, 4:14 PM
that makes sense
my guess is that there's something a little bit unusual with your project config that means more classes are being added than is usual
but also the executor isn't capable of handling large classpaths
m

Mitchell Syer

02/22/2023, 4:16 PM
It is a big project, but this is just a small module with a few dependencies, which makes it pretty weird
a

Adam S

02/22/2023, 4:18 PM
you're using Kotlin 1.7.10 - have you tried upgrading?
ah it's not the classpath that's big, it's the files set after the
-dependency-libraries
flag
m

Mitchell Syer

02/22/2023, 4:19 PM
Ya, we have a branch where everything is getting updated, I tried that after some other attempted fixes didn't work, and the same error still happened
a

Adam S

02/22/2023, 4:19 PM
173 libraries - but I have no point of reference, maybe that's big, but normal for macOS + Windows
try adding
org.gradle.logging.level=info
to the project's
gradle.properties
and syncing in IntelliJ. It should enable extra logs in the build window (View > Tool windows > build) Fetch the commonize command out again, and compare it to a successful commonize run from the command line
m

Mitchell Syer

02/22/2023, 4:31 PM
Done, its much smaller. but still outputs the same error
a

Adam S

02/22/2023, 4:49 PM
I've tried running my Kotlin/Native project that targets linux_x64, macos_x64, mingw_x64 and compared the output with yours. The only significant difference is the amount of dependency-libraries. I'm also using Kotlin 1.8 too, so maybe there was a fix since then. I think this is a problem worthy of an issue on YouTrack.
m

Mitchell Syer

02/22/2023, 5:07 PM
Ill see if I can reproduce it on a clean project
I was able to make a reproducible sample, does it happen on your end with this?
a

Adam S

02/22/2023, 5:44 PM
it works for me, IntelliJ can sync it
m

Mitchell Syer

02/22/2023, 5:45 PM
Weird, its the same error for me
a

Adam S

02/22/2023, 5:46 PM
I see in the build logs
Copy code
> Task :commonizeNativeDistribution
  Warning: No libraries found for target macos_arm64. This target will be excluded from commonization.
  Warning: No libraries found for target macos_x64. This target will be excluded from commonization.

> Task :commonizeCInterop
  Warning: No libraries found for target macos_arm64. This target will be excluded from commonization.
  Warning: No libraries found for target macos_x64. This target will be excluded from commonization.
m

Mitchell Syer

02/22/2023, 6:09 PM
Ok I found the reason, I had used https://github.com/LouisCAD/CompleteKotlin on another project and it seems as long as I use the same kotlin version as the one in that project, macOS targets get enabled
a

Adam S

02/22/2023, 6:12 PM
@louiscad FYI ⬆️
j

Jeff Lockhart

02/22/2023, 10:34 PM
Interesting, this seems to be similar to the error I ran into when I added that plugin. Besides removing the plugin, I had to remove the files it added to
~/.konan
to resolve the error. I'd be interested if there's a fix for this that allows using the plugin.
e

ephemient

02/22/2023, 10:35 PM
I think the proper fix would be for the plugin to create a new Konan distribution instead of mucking around with the existing one
l

louiscad

02/23/2023, 9:13 AM
@ephemient Not really.
Adding this line to your
gradle.properties
might do, can you try?
Copy code
kotlin.native.ignoreDisabledTargets=true
12 Views