Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
11 Views

Unresolved externals in release mode

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.

0 Kudos
4 Replies
Highlighted
11 Views

It would be more informative

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.

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
11 Views

Hi Steve, I just sent you a

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

0 Kudos
Highlighted
11 Views

Thanks to the info John sent

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.

Retired 12/31/2016
0 Kudos
Highlighted
11 Views

This is fixed in Update 3.

This is fixed in Update 3.

Retired 12/31/2016
0 Kudos