<@UJRUJP0F9> - With the new linker it doesn't like...

# kotlin-native

[napperley]

@Artyom Degtyarev [JB] - With the new linker it doesn't like dealing with symbolic links (often used in linking with the Linux ARM targets and the linuxX64 target). Is there a way to get the new linker to recognise a symbolic link to a Shared Library?

Do note that the linking issues don't occur when Kotlin is downgraded from 1.5.10 to 1.4.31 (uses the old linker).

[napperley]

Here is the build log.

linuxArm32_build.log

[sergey.bogolepov]

As I told you before, you can use ld.lld to return the old behaviour.

[napperley]

The issue referred to in the link isn't the same one mentioned in this thread. Upon closer inspection 🔍 of the log file there are some symbols that can't be resolved by the linker, even though the Shared Library files have been found via the Symbolic links. Recompiling GTK, and the associated GObject libraries (GIO, GLib etc) isn't a feasible option given how very complicated it is to compile Gtk from source (most applications just do dynamic linking to an existing Gtk library). Reverting to the old linker would fix the issue however that has the following problems:
• Is a band-aid fix 🩹; using a strict linker will mean the issue appears again
• It isn't known how long the old linker will be around (the fix shouldn't be relied on)
• If one module in a Multiplatform project is using a different linker from the others then there will be inconsistent linking behaviour occurring, which makes troubleshooting more difficult than it should be
Do note that there is no error message in the log file about the GLIBC version.