.dll and .exe are 3x bigger in ifort 2019 than they are in ifort 2013

[Johannes_A_]

Dear all,

In August this year I upgraded my 2013 Fortran Compiler. The code was compiled and linked without any problem either  by  .bat or by VS.

However,  the new  .dll is 3 times bigger than the old one (same for .exe). For a software distribution it makes a difference whether the user has 30 MB or 100 MByte to download. Of coarse I want to distribute a small setup file.

This is the situation on the day I changed for the new compiler:

"Intel2013":    16.08.2019  16:36        29,507,072        abc_run.dll 

"Intel2019":    17.08.2019  16:12       104,326,144       abc_run.dll

The problem with size hasn't changed since then even if I now use other compile options.

• Did I miss a linker option?
• if I zip the new .dll it comes back to about 30 MB. Coincidence or is there something behind it?
• Do I have to live with it?

This way I did compile and link: 

2013:
ifort -c /Qopenmp /Qmkl:parallel /O3 /Qvec /arch:SSSE3  /heap-arrays:2000000 Solver.f90
etc.
 
2019 (Version 19.0.4.245 Build 20190417):
ifort -c /Qopenmp /Qmkl:parallel  /QxSSE4.2  /arch:corei7 /tune:corei7 /heap-arrays:2000000 Solver.f90
etc
 
2013:
link /dll  abc_run.obj module_global3.obj module_model3.obj module_body3.obj lapack.obj trm$tool3.obj trm$lib3.obj  materials3.obj   GUIcompose3.obj PRJBody.obj NetandMaterial.obj Solver.obj CSR3riters.obj dislin.obj compiler-tag_ifort.obj  disifl.lib /DEFAULTLIB:gdi32.lib user32.lib mkl_lapack95_ilp64.lib   
 
2019 (Version 19.0.4.245 Build 20190417):
link /dll  abc_run.obj module_global3.obj module_model3.obj module_body3.obj lapack.obj trm$tool3.obj trm$lib3.obj  materials3.obj   GUIcompose3.obj PRJBody.obj NetandMaterial.obj Solver.obj CSR3riters.obj dislin.obj compiler-tag_ifort.obj  disifl.lib /DEFAULTLIB:gdi32.lib user32.lib mkl_lapack95_ilp64.lib

Best Regards,

Johannes

[Steve_Lionel]

You should use /dll on the ifort command as well. See what that does for you.

[Johannes_A_]

Hi Steve,

I did add /dll and it doesn't link anymore. Only can offer the messages in German: 

LINK : warning LNK4098: Standardbibliothek "LIBCMT" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden.
disifl.lib(resall.obj) : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "fprintf" in Funktion "inipsc".
disifl.lib(qqppng.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "fprintf".
disifl.lib(disini.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "fprintf".
disifl.lib(errmes.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "fprintf".
disifl.lib(line.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "fprintf".
disifl.lib(qqwini.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "fprintf".
abc_run.dll : fatal error LNK1120: 1 nicht aufgelöste Externe

The link command was truncated in my initial post. Here it is again with extra line feeds:

link /dll  abc_run.obj module_global3.obj module_model3.obj module_body3.obj lapack.obj trm$tool3.obj trm$lib3.obj  materials3.obj GUIcompose3.obj PRJBody.obj NetandMaterial.obj Solver.obj AC.obj CSR3riters.obj dislin.obj compiler-tag_ifort.obj  disifl.lib /DEFAULTLIB:gdi32.lib user32.lib mkl_lapack95_ilp64.lib

Somehow disifl.lib (DISLIN) seems to be in conflict with "LIBCMT".

Changing to  /NODEFAULTLIB:disifl.lib is creating even more messages.

BR
Johannes

[Johannes_A_]

One more posting of the link command with line feeds:   

link /dll abc_run.obj module_global3.obj module_model3.obj module_body3.obj lapack.obj trm$tool3.obj trm$lib3.obj  

   materials3.obj   GUIcompose3.obj PRJBody.obj NetandMaterial.obj Solver.obj AC.obj CSR3riters.obj dislin.obj

   compiler-tag_ifort.obj  disifl.lib /DEFAULTLIB:gdi32.lib user32.lib mkl_lapack95_ilp64.lib 

[Steve_Lionel]

Ok - the DISLIN library is built to link to the static MSVC library, therefore it's not compatible with linking against DLL libraries. (This happens with C/C++ code - Intel Fortran compiled code can link to either.)

Because everything is linking statically, you are pulling in the Intel and MSVC static libraries. Next thing to do is to add /map to the link command in both versions and look at the various things pulled in and their sizes, to see which contribution accounts for the discrepancy.

[Andrew_Smith]

I recently upgraded from XE 2016 to XE 2019 and my dll increased from 17.0 Mb to 17.8 Mb. Not a significant change.

[Johannes_A_]

Hi Andy,

that's also my observation for my other codes. They also use DISLIN but not Lapack.

3x bigger exe seems to be caused by the additional use of lapack (pardiso solver). Could that be?

BR

Johannes

[JohnNichols]

I use pardiso in a structural analysis package which handles large problems -- it is 856 KB in size. 

[Johannes_A_]

Then it must be something else.  At some point it will turn out. 
 

[Brian_Murphy]

When I build a Debug version with 19.1 (/libs:static /threads /dbglibs), my exe file is over 50 mb. With 13.0.3636.2010 the exe file is less than 20 mb.  The dependencies are the same for both (i.e. only libiomp5md.dll).  I notice mkl_core.dll files are much larger with 19.1.  Is that the reason for the jump in size?