This is just an observation when x-compiling with NIM.
I had a weird problem when x-compiling my crypto lib with MinGW. In particular
I needed to import some Windows crypto provider stuff from <wincrypt.h> for
compiling
[https://github.com/mjfh/nim-crypto/blob/unstable/src/lib/ltc/getbytes.nim](https://github.com/mjfh/nim-crypto/blob/unstable/src/lib/ltc/getbytes.nim).
See below for a minimalised NIM source causing the problem.
# nim test file: problem.nim
# C file equivalent of:
# #define WIN32_LEAN_AND_MEAN
# #include <windows.h>
# #include <wincrypt.h>
# printf(">>> PROV_RSA_FULL=%d\n", PROV_RSA_FULL);
{.passC: "-DWIN32_LEAN_AND_MEAN".}
var PROV_RSA_FULL {.importc,
header: "<windows.h>",
header: "<wincrypt.h>".}: int
echo ">>> PROV_RSA_FULL=", PROV_RSA_FULL
On a native MinGW this just noisily fails which is OK. So I know that I have to
do it the other way writing C code. The problem appeared on my Linux/amd64 when
I initially compiled it for a Win32 as shown below.
# config file: nim.cfg
cpu = i386
i386.windows.gcc.path = "/usr/bin"
i386.windows.gcc.exe = "i686-w64-mingw32-gcc"
i386.windows.gcc.linkerexe = "i686-w64-mingw32-gcc"
# command line compiler directive
nim cc --os:windows --verbosity:3 --listCmd problem.nim
The compiler process just hangs with an output like
...
lib/system.nim(3806, 1) Hint: 103201 [Processing]
Hint: problem [Processing]
problem.nim(3, 1) Hint: 104003 [Processing]
problem.nim(4, 1) Hint: 104003 [Processing]
problem.nim(8, 6) Hint: 104005 [Processing]
/usr/bin/i686-w64-mingw32-gcc -c -w -DWIN32_LEAN_AND_MEAN
-I/usr/local/share/nim/lib -o /home/jordan/Desktop/nimcache/problem.o
/home/jordan/Desktop/nimcache/problem.c
And this is the part of the process table
10675 pts/11 S+ 0:00 \_ /usr/local/share/nim/bin/nim cc
--os:windows --verbosity:3 --listCmd problem.nim
10677 pts/11 S+ 0:00 \_ /bin/sh -c
/usr/bin/i686-w64-mingw32-gcc -c -w -DWIN32_LEAN_AND_MEAN
-I/usr/local/share/nim/lib -o /home/jordan/Desktop/nimc
10678 pts/11 S+ 0:00 \_ /usr/bin/i686-w64-mingw32-gcc -c
-w -DWIN32_LEAN_AND_MEAN -I/usr/local/share/nim/lib -o
/home/jordan/Desktop/nimcache/prob
10679 pts/11 S+ 0:00 \_
/usr/lib/gcc/i686-w64-mingw32/6.3-win32/cc1 -quiet -I /usr/local/share/nim/lib
-U_REENTRANT -D WIN32_LEAN_AND_MEAN /ho
It took me a while to realise that NIM was waiting for something it never got.
In other instances I saw zombie processes below the latest gcc but cannot
reproduce it after NIM + gcc update (maybe not the reason). Running the GCC
command directly as indicated with the '\--listCmd' option, GCC aborts nosily.
The behaviour might happen in another context as well - not a big deal but very
annoying at first.
Jordan
