WIndows build for c++

I tried without success to build this weekend. It ends up creating a 1.8GB dll (debug) but fails on the creation of the op.h. (Looks like that is being done with an external python tool instead of cmake built in GENERATE facility and there are some dependencies it cannot find from within visual studio)

First I need to figure out how to get it built but also I have a question. 1.8GB is ridiculous for a single dll, especially for a “lightweight framework” and the build time is multiple hours which is also suspect. (VS2017 building 2015 project on 12 core xeon 3.6Ghz with 12G ram and stripped SSD)

  1. How do I build this thing? Why are there no pre-builts (number of options? or just does not build)
  2. If building from source, how long should it take and what output should I expect size of dll(s) and their names
  3. Is debug ABI compatible?, can I build a debug app and link against a release dll(lib)

The dll does not have any indication of debug vs release, if I build the install task will it go into a different directory or when I build the release and install it will it wipe each other out?

I am not an expert but checking the dll from anaconda it is around 200mb. 1.8gb in debug is not that unusual in my opinion.

$ ls -lah *dll
-rwxrwx— 1 kuent mkpasswd 321M Jun 24 09:16 cudnn64_7.dll
-rwxrwx— 1 kuent mkpasswd 81K Jun 24 09:16 libgcc_s_seh-1.dll
-rwxrwx— 1 kuent mkpasswd 1.3M Jun 24 09:16 libgfortran-3.dll
-rwxrwx— 1 kuent mkpasswd 194M Jun 24 09:16 libmxnet.dll
-rwxrwx— 1 kuent mkpasswd 41M Jun 24 09:16 libopenblas.dll
-rwxrwx— 1 kuent mkpasswd 324K Jun 24 09:16 libquadmath-0.dll

I build from source in windows10 (release) and the resulting dll is indeed quite big. And it is 7 times bigger what we have in anaconda. Are we doing something wrong here?

$ ls -lah
total 1.4G
d--------- 1 kuent mkpasswd 0 Jul 10 19:58 .
d--------- 1 kuent mkpasswd 0 Jul 10 19:58 …
---------- 1 kuent mkpasswd 704K Jul 10 19:58 im2rec.exe
---------- 1 kuent mkpasswd 1.4G Jul 10 19:58 libmxnet.dll
---------- 1 kuent mkpasswd 59K Jul 10 19:57 libmxnet.exp
-rwxrwx— 1 kuent mkpasswd 98K Jul 10 19:57 libmxnet.lib

I was able to find a pre-built online and the CPU is 200Mb and the GPU is just under a GIG. I am guessing we have a monolithic dll containing all you might ever need, (the exact wrong way to use dll’s as the thing would load into memory then swap out.) In the same way I have not checked to see if it is built /MT or /MD which would mean statically linked with the mslibs or dynamically. statically can blow up a dll.
This also means I need to check if the license for mxnet lets me static link as then the resulting application would only be as big as it needs.

This is awful. Not once has this successfully built. The latest is a release with the project set to /MT

This cuases a bloating of the dll and insecurity if it built, but it failed becasue some(or dependencies) are set /MD and some /MT.

Is there a special reason to change to /MT? or is it possible that the maintainer does not understand the difference /MT == static link microsoft runtime. /MD == Use system runtime