nimforum mirror - NIM compiler looses track of sub-processes on Linux

jordan (orginal) [2017-05-09T20:05:01+02:00] view original

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. 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

Mirror of forum.nim-lang.org

2953 :: NIM compiler looses track of sub-processes on Linux