I'm using VS2015 Community. I have obtained some C code that I'm trying to build. It is all in C and I have made a project as a Console Application.
When I build I get the below errors. The problem is that __stdio_common_vsprintf_s cannot be found during the link process. So I searched the internet for the symbols but don't get any useful information.
I am using the Runtime Library setting called Multi-threaded (/MT).
I have tried adding #define STDC_WANT_LIB_EXT1 1 before all includes but that did not help. I have searched for this problem and have not found any postings that help.
So I searched all of the VS libraries and got lots of hits but I don't know which are definitions and which are references. Then I searched all of the .h files in the VS include folder but no hits.
I suspect there may be another library that I need but don't know what it is. Does anyone have any ideas?
1>LIBCMT.lib(_error_.obj) : error LNK2019: unresolved external symbol ___stdio_common_vsprintf_s referenced in function __vsprintf_s_l
1>LIBCMT.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol ___vcrt_GetModuleFileNameW referenced in function "int __cdecl _RTC_GetSrcLine(unsigned char *,wchar_t *,unsigned long,int *,wchar_t *,unsigned long)" (?_RTC_GetSrcLine##YAHPAEPA_WKPAH1K#Z)
1>LIBCMT.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol ___vcrt_LoadLibraryExW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDllFromInstallPath(void)" (?GetPdbDllFromInstallPath##YAPAUHINSTANCE__##XZ)
1>MSVCRTD.lib(_chandler4gs_.obj) : error LNK2019: unresolved external symbol __except_handler4_common referenced in function __except_handler4
1>W:\efifs\Debug\testing.exe : fatal error LNK1120: 6 unresolved externals
Here are my options:
Compile
----------
/GS
/analyze-
/W3
/Zc:wchar_t
/I"W:\efifs\\gnu-efi\inc"
/I"W:\efifs\\gnu-efi\inc\ia32"
/I"W:\efifs\\grub\include"
/I"W:\efifs\\grub-core\lib\minilzo"
/I"W:\efifs\testing\"
/I"W:\efifs\\gnu-efi\inc\protocol"
/I"W:\efifs\\gnu-efi\lib"
/I"W:\efifs\\include"
/I"W:\efifs\\grub\grub-core\lib\minilzo"
/I"W:\efifs\.msvc"
/ZI
/Gm
/Od
/Fd"Debug\vc140.pdb"
/Zc:inline
/fp:precise
/D "__STDC_WANT_LIB_EXT1__=1"
/D "_UNICODE"
/D "UNICODE"
/D "GRUB_FILE=__FILE__"
/D "HAVE_USE_MS_ABI"
/D "GNU_EFI_USE_EXTERNAL_STDARG"
/D "DRIVERNAME=testing"
/D "WIN32"
/D "_DEBUG"
/D "_CONSOLE"
/errorReport:prompt
/WX-
/Zc:forScope
/RTC1
/Gd
/Oy-
/MT
/Fa"Debug\"
/EHsc
/nologo
/Fo"Debug\"
/Fp"Debug\testing.pch"
Link
-----
/OUT:"W:\efifs\Debug\testing.exe"
/MANIFEST
/NXCOMPAT
/PDB:"W:\efifs\Debug\testing.pdb"
/DYNAMICBASE "efifs.lib" "grub.lib" "gnu-efi.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib"
/MACHINE:X86
/INCREMENTAL
/PGD:"W:\efifs\Debug\testing.pgd"
/SUBSYSTEM:CONSOLE
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"Debug\testing.exe.intermediate.manifest"
/ERRORREPORT:PROMPT
/NOLOGO
/LIBPATH:"W:\efifs\testing\\grub"
/LIBPATH:"W:\efifs\testing\\efifs"
/LIBPATH:"W:\efifs\testing\\gnu-efi"
/TLBID:1
If you look how vsprintf is declared you can trace it corecrt_stdio ... where it says to inline it.
I had some old DLL which were linking against old msvcrt and trying to import vsprintf from it but seems like VS2015 have new headers and trying to inline it.
Setting _NO_CRT_STDIO_INLINE helped to resolve it, Enjoy.
Edit: Also https://msdn.microsoft.com/en-us/library/bb531344.aspx
You configuration appears to be incorrect. You don't seem to be linking with a couple of new libraries added in Visual Studio 2015's reorganization of the C runtime library. You also appear to linking with both the release static (/MT) and debug DLL (/MDd) version of the same library, specifically LIBCMT.lib and MSVCRTD.lib.
The symbol ___stdio_common_vsprintf_s can be found in the in Universal CRT which part of the Windows 10 SDK. The release static version of the library is called libucrt.lib. The other unresolved symbols are part of "vcruntime" library which is part of Visual Studio 2015. The name of it's release static version is libvcruntime.lib.
It not clear why you're not linking with the correct libraries. Normally this handled automatically for you. You'll need to check to your project's configuration settings to see where you've overridden the default behaviour.
You need insert this line
#define _NO_CRT_STDIO_INLINE
According to the C standard annex K
K.3.1.1 Standard headers
The functions, macros, and types declared or defined in K.3 and its subclauses are not
declared or defined by their respective headers if _ _STDC_WANT_LIB_EXT1_ _ is
defined as a macro which expands to the integer constant 0 at the point in the source file
where the appropriate header is first included.
Meaning that in order to use the "_s" functions such as vsprintf_s, which are all found in the mentioned annex, you must define that macro to a value other than 0 before including the header files.
#define __STDC_WANT_LIB_EXT1__ 1
#include <stdarg.h>
#include <stdio.h>
I suspect that you must have a C11 compiler. Whether or not Visual Studio follows that standard, I have no idea. It is notorious for its poor standard conformance.
Related
I am using Microsoft (R) Incremental Linker Version 14.16.27041.0 both from the command line and via a Visual Studio project.
I am compiling and linking the following well-known program residing in a file called HelloWorld.c:
#include "stdio.h"
int main() {
printf("Hello World !\n");
return 0;
}
The sizes of the respective *.exe files differ in a remarkable way:
a) Compiled and linked as a VS project using the default linker options from the VS Debug Build:
/OUT:"D:\HelloWorld.exe" /MANIFEST /NXCOMPAT /PDB:"D:\00_HelloWorld.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG:FASTLINK /MACHINE:X86 /INCREMENTAL /PGD:"D:\00_HelloWorld.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"Debug\00_HelloWorld.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
38,400 HelloWorld.exe
b) Compiled and linked on the command line:
link /OUT:HelloWorld.exe HelloWorld.obj
102,400 HelloWorld.exe
I tried to figure out which of the additional linker options that VS provided could lead to the smaller executable, but could not find any, especially as /OPT:ICF and /OPT:REF (the ones that seemed to be the most likely candidates in my opinion) are enabled automatically when link.exe is invoked at the command line, as it says here: /OPT (Optimizations) MSVC Linker Reference
Can anybody explain these different sizes ?
EDIT:
The program was compiled using
a)
/JMC /permissive- /GS /analyze- /W3 /Zc:wchar_t /ZI /Gm- /Od /sdl /Fd"Debug\vc141.pdb" /Zc:inline /fp:precise /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MDd /FC /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\00_HelloWorld.pch" /diagnostics:classic
b)
cl /c HelloWorld.c
It is the /MD compiler(!) option that is responsible for the different sizes.
Compiling the above program like so:
cl /c /MD HelloWorld.c
and linking it in the same way like above:
link /OUT:HelloWorld.exe HelloWorld.obj
yields the following executable:
8,192 HelloWorld.exe
The /MD option instructs the compiler to produce an object file with a built-in library name MSVCRTD.lib that acts as am internmediate layer between the program and the CRT residing in a DLL called MSVCRversionnumber.DLL. (See also here for more information: /MD option MSVC compiler). Not using this option results in a executable with statically linked CRT libs, hence the larger size.
Note that this way of compiling and linking C/C++ programs does require the existence of the aforementioned DLL on the target platform (including version number).
When I try to build a program using Eclipse CDT, I get the following:
/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x106):
undefined reference to `WinMain#16
Why is that? And, how can I solve this issue?
This error occurs when the linker can't find WinMain function, so it is probably missing. In your case, you are probably missing main too.
Consider the following Windows API-level program:
#define NOMINMAX
#include <windows.h>
int main()
{
MessageBox( 0, "Blah blah...", "My Windows app!", MB_SETFOREGROUND );
}
Now let's build it using GNU toolchain (i.e. g++), no special options. Here gnuc is just a batch file that I use for that. It only supplies options to make g++ more standard:
C:\test> gnuc x.cpp
C:\test> objdump -x a.exe | findstr /i "^subsystem"
Subsystem 00000003 (Windows CUI)
C:\test> _
This means that the linker by default produced a console subsystem executable. The subsystem value in the file header tells Windows what services the program requires. In this case, with console system, that the program requires a console window.
This also causes the command interpreter to wait for the program to complete.
Now let's build it with GUI subsystem, which just means that the program does not require a console window:
C:\test> gnuc x.cpp -mwindows
C:\test> objdump -x a.exe | findstr /i "^subsystem"
Subsystem 00000002 (Windows GUI)
C:\test> _
Hopefully that's OK so far, although the -mwindows flag is just semi-documented.
Building without that semi-documented flag one would have to more specifically tell the linker which subsystem value one desires, and some Windows API import libraries will then in general have to be specified explicitly:
C:\test> gnuc x.cpp -Wl,-subsystem,windows
C:\test> objdump -x a.exe | findstr /i "^subsystem"
Subsystem 00000002 (Windows GUI)
C:\test> _
That worked fine, with the GNU toolchain.
But what about the Microsoft toolchain, i.e. Visual C++?
Well, building as a console subsystem executable works fine:
C:\test> msvc x.cpp user32.lib
x.cpp
C:\test> dumpbin /headers x.exe | find /i "subsystem" | find /i "Windows"
3 subsystem (Windows CUI)
C:\test> _
However, with Microsoft's toolchain building as GUI subsystem does not work by default:
C:\test> msvc x.cpp user32.lib /link /subsystem:windows
x.cpp
LIBCMT.lib(wincrt0.obj) : error LNK2019: unresolved external symbol _WinMain#16 referenced in function ___tmainCRTStartu
p
x.exe : fatal error LNK1120: 1 unresolved externals
C:\test> _
Technically this is because Microsoft’s linker is non-standard by default for GUI subsystem. By default, when the subsystem is GUI, then Microsoft's linker uses a runtime library entry point, the function where the machine code execution starts, called winMainCRTStartup, that calls Microsoft's non-standard WinMain instead of standard main.
No big deal to fix that, though.
All you have to do is to tell Microsoft's linker which entry point to use, namely mainCRTStartup, which calls standard main:
C:\test> msvc x.cpp user32.lib /link /subsystem:windows /entry:mainCRTStartup
x.cpp
C:\test> dumpbin /headers x.exe | find /i "subsystem" | find /i "Windows"
2 subsystem (Windows GUI)
C:\test> _
No problem, but very tedious. And so arcane and hidden that most Windows programmers, who mostly only use Microsoft’s non-standard-by-default tools, do not even know about it, and mistakenly think that a Windows GUI subsystem program “must” have non-standard WinMain instead of standard main. In passing, with C++0x Microsoft will have a problem with this, since the compiler must then advertize whether it's free-standing or hosted (when hosted it must support standard main).
Anyway, that's the reason why g++ can complain about WinMain missing: it's a silly non-standard startup function that Microsoft's tools require by default for GUI subsystem programs.
But as you can see above, g++ has no problem with standard main even for a GUI subsystem program.
So what could be the problem?
Well, you are probably missing a main. And you probably have no (proper) WinMain either! And then g++, after having searched for main (no such), and for Microsoft's non-standard WinMain (no such), reports that the latter is missing.
Testing with an empty source:
C:\test> type nul >y.cpp
C:\test> gnuc y.cpp -mwindows
c:/program files/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libmingw32.a(main.o):main.c:(.text+0xd2): undefined referen
ce to `WinMain#16'
collect2: ld returned 1 exit status
C:\test> _
To summarize the above post by Cheers and hth. - Alf, Make sure you have main() or WinMain() defined and g++ should do the right thing.
My problem was that main() was defined inside of a namespace by accident.
I was encountering this error while compiling my application with SDL. This was caused by SDL defining it's own main function in SDL_main.h. To prevent SDL define the main function an SDL_MAIN_HANDLED macro has to be defined before the SDL.h header is included.
Try saving your .c file before building. I believe your computer is referencing a path to a file with no information inside of it.
My situation was that I did not have a main function.
Had same problem. To fix it I clicked save to save my .c file before building. I believe my computer was referencing a path to a file with no information inside of it.
Check that All Files are Included in Your Project:
I had this same error pop up after I updated cLion. After hours of tinkering, I noticed one of my files was not included in the project target. After I added it back to the active project, I stopped getting the undefined reference to winmain16, and the code compiled.
Edit: It's also worthwhile to check the build settings within your IDE.
(Not sure if this error is related to having recently updated the IDE - could be causal or simply correlative. Feel free to comment with any insight on that factor!)
I have compiled 32-bit dll library and I have its source and header file. The library is somehow showing print dialog and allows me to print files. I've made 32-bit C# application, which calls printing function in dll and everything is nice.
However, now I need to recompile library to 64-bit (Recompiling my C# project is easy). Basicly I tried two methods.
First one was compiling from Visual's Studio Developer command prompt. This was first time compiling something using command line, so I googled what should I write. I was not attempting to specify 64-bit architecture, because I wanted to be sure that it is working. I used this command to build it.
cl /D_USRDLL /D_WINDLL printing.c User32.Lib WinSpool.Lib Gdi32.Lib ComDlg32.Lib /link /DLL /OUT:printing.dll
It made printing.dll for me, I tried to replace precompiled version I already had and I tried it using my C# app. Everything worked. So I wanted to compile it as 64-bit library. I googled and found out, that I have to use different cl.exe and link.exe located in Program Files\Microsoft Visual Studio 12.0\VC\bin\amd64. So I cd-ed to correct folder and wrote same command. I've got bunch (29) of "unresolved externals", I googled and found out that it is because I am trying to link 32-bit libraries. So I changed all *.Lib-s to C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64*.Lib", retried and still got some (16) unresolved extarnals. Here is the list
/out:printing.exe
/DLL
/OUT:D:\Temp\printing\printing.dll
printing.obj
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\User32.Lib"
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\WinSpool.Lib"
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\Gdi32.Lib"
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\ComDlg32.Lib"
Creating library D:\Temp\printing\printing.lib and object D:\Temp\printing\printing.exp
printing.obj : error LNK2019: unresolved external symbol __report_rangecheckfailure referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol strcpy referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol strcmp referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol strlen referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_CreateFileA referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_ReadFile referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_CloseHandle referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_GlobalFree referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __imp_LocalAlloc referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol __imp_LocalHandle referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol __imp_LocalFree referenced in function RSS_PrintFileBez
printing.obj : error LNK2019: unresolved external symbol atoi referenced in function RSS_PrintFileBezFromTo
printing.obj : error LNK2001: unresolved external symbol __GSHandlerCheck
printing.obj : error LNK2019: unresolved external symbol __security_check_cookie referenced in function RSS_PrintFile
printing.obj : error LNK2019: unresolved external symbol __security_cookie referenced in function RSS_PrintFile
LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup
D:\Temp\printing\printing.dll : fatal error LNK1120: 16 unresolved externals
I managed to get rid of 4 unresolved externals adding /GS- option to compiler, but I do not know how to fix rest and I could not find any help. So I decided to use Microsoft Visual Studio to build my libary.
I've created new C++ project, set it to be a DLL library, added source and header file, compiled (using standart settings, on 32-bit). I've got bunch of warnings like this one
'function' : incompatible types - from 'char *' to 'LPCWSTR'
and simmilars and one error
'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
So I #include _CRT_SECURE_NO_WARNINGS on first line of printing.c file. Hiting "Build" button then resulted in 1 successful and I got my printing.dll. I replaced printing.dll I've got from command line by this one and I tested dll using my C# app. Pressing print button brought "Select Printer and so" window (as before), but hitting print resulted in opening small window with some chinese text. However, I can easily build it as 64-bit.
I would like to ask what am I doing wrong, why I can not compile C library from command prompt and why Microsoft visual studio somehow makes DLL not working.
I tried to debug DLL library compiled using MVS, but I failed. I do not know which solution should I open (C# testing app, or C DLL solution) and what to do next. C# wont show me code from another solution and even if I up debuger in DLL solution to open C# application it produces error
Debugginng information for "app.exe" could not be found or does not match. Skipped loading symbols for NGen binary.
and even if I press "Continue debugging", any breakpoint says, that it wont be hit, because no symbols were loaded.
So Basicly
How do I get rid of "unresolved externals" errors while compiling as 64-bit using command line?
OR
How do I fix Microsoft Visual Studio to built working dll library (does not matter if 32-bit or 64bit)?
Ok. I've managed to fix this issue. I gave up trying to build 64-bit version using command line and focused on fixing issue about chinese chars. I went to Project -> Project Properties -> Configuration Properties -> C/C++ -> Command Line to see what compiler parameters are passed. Then I went back to command line, and added previously found parameters one by one and testing if dll works. When I added /D "UNICODE", the library stopped working.
This being said, adding #undef UNICODE or setting Configuration Properties -> General -> Project Defaults -> Character Set to Not Set fixed my issue and now I a able to compile my printing library for both x86 and x64 architectures.
As the subject says, what I'm trying to do is similar to this but using Visual Studio 2012.
I can build and produce a DLL, and I can load that DLL in javascript, but I cannot access the function in that DLL. Looking at the DLL in DllExp shows no functions, suggesting something's wrong with the DLL.
The DLL is a new C++ project created using the "Empty Project" template. Notable settings are;
General->Configuration Type set to DLL
No optimization.
No precompiled headers.
Compile as C code
Calling convention __cdecl
The commandlines for compilation and linking, in case there's a setting I've not thought significant, are
/GS /TC /analyze- /W3 /Zc:wchar_t /ZI /Gm /Od /sdl /Fd"Debug\vc110.pdb" /fp:precise /D "_WINDLL" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MDd /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\StreamInterop.pch"
And for linker
/OUT:"C:\Work\VehicleTracker-DotNet\StreamInterop\Debug\StreamInterop.dll" /MANIFEST /NXCOMPAT /PDB:"C:\Work\VehicleTracker-DotNet\StreamInterop\Debug\StreamInterop.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"C:\Work\VehicleTracker-DotNet\StreamInterop\Debug\StreamInterop.lib" /DEBUG /DLL /MACHINE:X86 /INCREMENTAL /PGD:"C:\Work\VehicleTracker-DotNet\StreamInterop\Debug\StreamInterop.pgd" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"Debug\StreamInterop.dll.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /TLBI
The project contains a single C source file, main.c, containing
#include<stdio.h>
int add(int a,int b)
{
return(a+b);
}
Given this is all that was needed in the earlier post, it seems to me the problem must be in the compiler or linker switches. Can anyone see what I'm missing?
On Windows using Visual Studio, to export a function from a DLL, use:
#include<stdio.h>
__declspec(dllexport) int add(int a,int b)
{
return(a+b);
}
As a side note, don't choose Empty Project so Visual Studio will generate some example code for you.
I have written a C Program which calls the function, GetModuleInformation() which is defined in psapi.h
I am using Microsoft Visual Studio C++ command line compiler (cl.exe) for compiling and linking the program.
I have included the psapi.h header file:
#include <psapi.h>
when I try to compile using:
cl program.c
It generates the object file, however fails during the linking stage with the error:
program.obj : error LNK2019: unresolved external symbol _GetModuleInformation#16 ref
erenced in function _main
program.exe : fatal error LNK1120: 1 unresolved externalsprogram.obj : error LNK2019: unresolved external symbol _GetModuleInformation#16 ref
I also place the psapi.lib file in the same folder where the source code file (program.c) is placed, however even then I get the same error message as above.
How do I successfully link it using the command line compiler (cl.exe)?
Method 1
If you want to compile from the command line with cl.exe you can use the /link option to specify linker options :
cl /TC program.c /link psapi.lib
Method 2
The following pragma directive causes the linker to search in your source file for the psapi.lib library while linking .
#pragma comment( lib, "psapi.lib" )
Possible reason for your errors can be, if psapi.lib is missing in a list of additional libraries of linker.
To resolve this, use the following /LIBPATH option :
cl /TC program.c /link Psapi.Lib /LIBPATH:C:\MyLibFolder\
Where C:\MyLibFolder specifies a path to the folder, that contains your psapi.lib .
Also, you can try to set the proper /SUBSYSTEM option .
For a Console application use :
/SUBSYSTEM:CONSOLE
Solution to similar problem here .
Example on using the GetModuleInformation function :
#include <windows.h>
#include <stdio.h>
#include <psapi.h>
#pragma comment( lib, "psapi.lib" )
int main(void)
{
MODULEINFO minfo = {0};
GetModuleInformation( GetCurrentProcess(), GetModuleHandle( "psapi.dll" ), &minfo, sizeof(minfo) );
/* printf("%X", minfo.lpBaseOfDll); /* The load address of the module */
return 0;
}
The code has been tested on Windows 7 and XP .
The output from linking session is :
program.c
/out:program.exe
psapi.lib
/LIBPATH:C:\MyLibFolder\
/SUBSYSTEM:CONSOLE
/VERBOSE
program.obj
Starting pass 1
Processed /DEFAULTLIB:uuid.lib
Processed /DEFAULTLIB:LIBCMT
Processed /DEFAULTLIB:OLDNAMES
Searching libraries
Searching C:\MyLibFolder\psapi.lib:
Found _GetModuleInformation#16
Referenced in program.obj
Loaded psapi.lib(PSAPI.DLL)
Found __IMPORT_DESCRIPTOR_PSAPI
Referenced in psapi.lib(PSAPI.DLL)
Loaded psapi.lib(PSAPI.DLL)
Found __NULL_IMPORT_DESCRIPTOR
Referenced in psapi.lib(PSAPI.DLL)
Loaded psapi.lib(PSAPI.DLL)
...
If vsvars32.bat and all appropriate environment variables in your Visual Studio are set correctly the above linker options will produce a valid executable(.exe) file.