Kotlin-native: Linker error using FOLDERID_Documents

Created on 8 Apr 2019  路  7Comments  路  Source: JetBrains/kotlin-native

In a mingw target, we want to use FOLDERID_Documents from platform.windows.*, but doing so causes a linker error: undefined reference to 'FOLDERID_Documents'. I've attached a minimal sample project that reproduces the error. It would be great to either resolve this in Kotlin-Native or learn what linker flag we should be using.

winTest.zip

Most helpful comment

--- a/build.gradle
+++ b/build.gradle
@@ -15,6 +15,7 @@ kotlin {
             outputKinds("executable")
             // Change to specify fully qualified name of your application's entry point:
             entryPoint 'sample.main'
+            linkerOpts '-luuid'
         }
     }
     sourceSets {

All 7 comments

We tried -lshell32, which didn't work (suggestion from slack).

--- a/build.gradle
+++ b/build.gradle
@@ -15,6 +15,7 @@ kotlin {
             outputKinds("executable")
             // Change to specify fully qualified name of your application's entry point:
             entryPoint 'sample.main'
+            linkerOpts '-luuid'
         }
     }
     sourceSets {

@msink that did it thanks!. @olonho is this something that can be fixed in K/N?

In theory, we could have that in default DLLs to link, but in fact I think it's better to somewhat split Windows platform libs somehow, instead of always linking everything. Do you have an idea how it better be done?

AFAIK, libuuid.a does not link any dll.

That makes sense. I think splitting up platform.windows.* into sub-packages based on the libraries the symbols come from would help. Initially, we could use that as a hint to know which linker flags we need. In the future, maybe a plugin could lean on that to know which linker flags to add?

OK, as quick workaround let's do d5096cbb1e14ed4f015cd63533f1b05a80fc03d4, but generally effort on splitting Windows platform lib from people more familiar with Win32 API would be awesome.

Was this page helpful?
0 / 5 - 0 ratings