asyncdispatch could not be linked to nimrtl

[enthus1ast]

testfile.nim:

import asyncdispatch

nim c -r -d:useNimRtl testfile.nim

build failes with:

Hint: used config file '/home/z/Nim/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: l [Processing]
Hint: asyncdispatch [Processing]
Hint: os [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: algorithm [Processing]
Hint: times [Processing]
Hint: posix [Processing]
Hint: ospaths [Processing]
Hint: tables [Processing]
Hint: hashes [Processing]
Hint: heapqueue [Processing]
Hint: lists [Processing]
Hint: options [Processing]
Hint: typetraits [Processing]
Hint: asyncstreams [Processing]
Hint: asyncfutures [Processing]
Hint: deques [Processing]
Hint: nativesockets [Processing]
Hint: net [Processing]
Hint: sets [Processing]
Hint: selectors [Processing]
Hint: epoll [Processing]
Hint: macros [Processing]
lib/pure/asyncdispatch.nim(1545, 61) template/generic instantiation from here
lib/pure/asyncmacro.nim(301, 55) Error: cannot 'importc' variable at compile time

[xomachine]

It is not only an asyncdispatch issue. Any usage of procs related to GC (e.g. strutils.split) in the compile time code with -d:useNimRtl causes this error.

[ccll]

@xomachine Yes, I've encountered the strutils error, related issue #8405.

[sinkingsugar]

Just when I was about to release a Unity plug-in... I hit this too...
What's weird is that even without nim rtl I have issues with async and gc.

[sinkingsugar]

Update:
In the case of Unity engine, actually any gc except regions/none will crash for some reason with the current nim. I will investigate more, hard to gdb unity reliably, repro is easy tho.

[sinkingsugar]

Update on my specific case, fixed, basically:
With this PR which is already in devel: #8975

In a nutshell:
Each dll will have a different C++ namespace so no useNimRtl is necessary at all.
Just one remark: using vars in the global scope is asking for trouble. Make sure your plugin dlls use something like a var ctx = cast[Context](alloc0(sizeof(Context))) to hold your context rather than global scope.

Having multiple GCs could be avoided but it's not going to be the end of the world unless you really have way too many dlls, but in that case you should have memory management built-in in your program. Can't wait for --gc:destructors indeed.