thx for clarifying, in my case I would need it for a very special static
analysis case, no big deal IMHO from a language perspective. Totally understand
why it is not supported, just wanted to double check I am not missing something.
Time to Deprecate some switches...
These things are not much of a problem but we don't support static linking of
the stdlib. Why not? Because the combinatorial explosion of switches is already
killing us.
People have talked about this before, and the problems come down to this:
> * GC would need to be ARC/ORC, otherwise you would need to manually import
> and call NimMain
> * You would need to create what would effectively be Nim header files to
> import the stdlib's procs
> * The compiler
I'm not sure a static version of nimrtl would even work. The whole point of
nimrtl is to make sure that each loaded dynamic library uses the same GC, with
the same state. By statically linking to it you would end up with a copy of the
global state which is the whole reason you'd use nimrtl in th
Hi, my goal is to statically compile nimrtl.nim, but
nim c -d:release --opt:size --app:staticlib --dynlibOverrideAll
--nimcache:.nimcachelocal --out:nimrtl.lib .nimrtl.nim
fails with a bunch of compiler error on e.g. CC: pure/os.nim In file included
from
C:Usershunte.choosenimtoolchainsnim-1.6
