Unresolved externals in release mode

[John_O_1]

My C++ / Fortran mixed language app builds fine in Debug mode, but in Release mode I get the following link errors. 

1>libirc.lib(irc_msg_support.obj) : error LNK2001: unresolved external symbol __imp__LoadLibraryA@4
1>libirc.lib(irc_msg_support.obj) : error LNK2001: unresolved external symbol __imp__GetThreadLocale@0
1>libirc.lib(intel_lib_vs_wrappers_init.obj) : error LNK2001: unresolved external symbol __imp__LoadLibraryExA@12
1>libirc.lib(intel_lib_vs_wrappers_init.obj) : error LNK2001: unresolved external symbol __imp__GetModuleHandleExA@12
1>libirc.lib(intel_lib_vs_wrappers_init.obj) : error LNK2001: unresolved external symbol __imp__GetEnvironmentVariableA@12
1>C:\Users\otakiej\Documents\Subversion\OPT_trunk\Windows10\OPT\Release\OPT\OPT.exe : fatal error LNK1120: 5 unresolved externals

I've compared the compiler and linker settings between the debug and release builds and they seem equivalent.  I'm using VS 2015 and Intel® Parallel Studio XE 2016 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2015, Version 16.0.0046.14.  Linker output with /verbose:lib is attached.  Please help.

[Steven_L_Intel1]

It would be more informative to see the buildlog.htm and perhaps the .vfproj file. It's not searching the Windows API libraries such as kernel32.lib. Normally this happens by default.

[John_O_1]

Hi Steve, I just sent you a message with those files attached.  Thanks in advance!

[Steven_L_Intel1]

Thanks to the info John sent me, I figured it out.

The problem occurs because of an Intel routine referenced in the Release build but not the Debug build. This in turn pulls in some code that uses the aforementioned Windows API routines that should be resolved from kernel32.lib. Normally no problem - the normal MSVC libraries have an "initializers" routine that is always pulled in, and this has the directive to trigger a search for kernel32.lib. However, John's build was configured to use the "store" variant of the MSVC libraries, and the initializers module there doesn't include the directive.

The workaround is to add kernel32.lib in Linker > Additional Dependencies to tell the linker to look there. We'll add the appropriate directive to our own code so that we don't rely on the MSVC library to do it.

[Steven_L_Intel1]

This is fixed in Update 3.