building problems

[Brian_Murphy]

I have a console app I can build in Release mode with either Multithreaded or Multithreaded DLL options for Libraries.  In Debug mode, I can build it with Multithreaded DLL, but not with Multithreaded because get over 1000 linker errors starting with the following:

Error 1324  error LNK2019: unresolved external symbol _vsprintf referenced in function _for__io_return libifcoremt.lib(for_diags_intel.obj) 
Error 1462  error LNK2019: unresolved external symbol _vsnprintf referenced in function ___libm_error_support libmmt.lib(libm_error.obj) 
Error 1305  error LNK2019: unresolved external symbol _toupper referenced in function _for_open libifcoremt.lib(for_open.obj) 
Error 1446  error LNK2019: unresolved external symbol _tolower referenced in function _for_check_env_name libifcoremt.lib(for_io_util.obj) 

Is there something obvious I might be doing wrong?

[Brian_Murphy]

After remaking the visual studio project from scratch, the console program now has a dependency on IMSL_DLL.DLL that it didn't have before.  What would cause this?  It used to have dependencies on several LIBIF*.DLL files that it doesn't have now..

[mecej4]

I gather that you have some calls to IMSL routines in your source code. If you opted to use the static IMSL libraries at link time, or by using a directive as in #11, the resulting EXE/DLL would have no dependencies on IMSL DLLs. 

In general, any DLL can depend on other DLLs. Therefore, changing the libraries used (static vs. dynamic, etc.) may change the dependency list of an EXE/DLL.

[Brian_Murphy]

Thanks.  The code does indeed use IMSL. 

I changed Static to Shared in the following, and the dependency changed from IMSL_DLL.DLL to LIBIOMP5MD.DLL.

        !DEC$ OBJCOMMENT LIB:'libiomp5md.lib'   
        !INCLUDE 'link_fnl_Static.h'

Is that what is supposed to happen?  I prefer the least number of dependencies.  IMSL_DLL.DLL has dependencies to 4 or 5 other LIBIF* files.  The Intel FAQ page for IMSL usage says to either use "shared.h", or if using "static.h" then to also have the libiomp5md part.  Is pairing "shared" with libiomp asking for trouble because that is the way the code was.

In many routines throughout the code I see USE IMSL_LIBRARIES and  USE linear_operators.  Some routines have both of these.  Is  USE IMSL_LIBRARIES sufficient for any use of IMSL?  I suspect it is.

I also see several instances of USE DFPORT.  What would those likely be for?  Is commenting out this line and compiling the file a good test of if it is needed.

[andrew_4619]

Well you cannot do static omp build so if you have OMP or any parallel options  or any libs that use parallel then you will have some dll dependencies. Read

https://software.intel.com/en-us/articles/openmp-static-library-deprecation-in-intelr-mkl-on-microsoft-windows

The dfport is now ifport (the dfport  module still exists but just says "use ifport"). These are portability routines. See https://software.intel.com/en-us/node/678976#BECB269E-D247-4434-AC0F-0C3CAE4CF854

I would not recommend commenting out as some of those routines have a routine of the same name in the C runtime so it might still link OK but not behave exactly the same. I always do "use ifport, only: routine-name" as then you know where you stand.....

[mecej4]

I think that you need to assess your needs a bit more fully before selecting the version of the IMSL libraries to link with.

The USE statements are for the purpose of making type definitions and subprogram interfaces available to the compiler when your code uses IMSL routines, especially if an explicit interface is required. Typically, USE statements only provide information to the compiler and not the linker. INCLUDE directives can be used to including anything, but in this thread the main purpose is to include INCLUDELIB directives to make linking easier. These directives cause the OBJ files produced by the compiler to contain references to the libraries needed, so the user does not need to tell the linker (either directly or through the compiler driver) which IMSL libraries to process.

Be aware that linking with static libraries can increase the EXE size quite considerably. As to redistributing DLLs that your EXE depends on, you need to follow the restrictions that your IMSL license imposes on such redistribution.

[Steve_Lionel]

You won't be able to avoid the dependency on libomp5md.dll. What you have in post 20 is correct to link to the static IMSL library, but you'll still get the DLL form of the OpenMP library as that's all there is nowadays.

[Brian_Murphy]

The exe got a bit bigger when I changed shared.h to static.h, but the increase is acceptable to me, especially since the total size is actually a lot smaller since the huge IMSL_DLL.DLL is not needed.

I would prefer not to use IMSL, but this is someone else's code (from a University), and IMSL is solidly entrenched.

I won't mess with the USE DFPORT lines.  Although I suppose I could change them to IFPORT.  I can't tack on the Only directive because I don't know what portability routines are being used.