I am using CreateProcess to invoke cl to compile and link another C++ program (TestProg.cxx) into a DLL. I invoke cl with the following compilation options:
/Od /nologo /Fo /RTC /w /Zc /EHsc /I\INCLUDE /I\LIB /I\PATH TestProg.cxx /DLL
the call:
if ( CreateProcess(full path to cl.exe, compilation options, NULL,NULL,FALSE,0, NULL,NULL,&si,&pi) )
{
//....
}
Running the application from VS tools prompt, I got the following linkage error:
LINK : fatal error LNK1561: entry point must be defined
What am I doing wrong?
I searched the answer for the last 1/2 day at the web, but didn't find it. Using windows API is new to me.
Thanks
That's not an error in using CreateProcess() to run the compiler, it's an error from the compiler telling you that your TestProg.cxx has no main() function. (Or DllMain(), since you seem to be building a DLL.)
You have a linker error, so linker was unable to build you a binary. The entry point can be provided via /ENTRY command line parameter, see MSDN for details:
/ENTRY (Entry-Point Symbol)
You will have something like: cl.exe /ENTRY:DllMain ... where DllMain will be your entry point function in source code.
Related
I need to compile a external source file from Visual Studio.
I picked that from the developer command prompt:
cl /EHsc test.cpp
So I tried this:
system("cl /EHsc test.cpp");
But the command 'cl' doesn't exist in the normal cmd that is called by system()
Any suggestions how to use the compiler function anyway?
Now I did it myself and for those ones who are curious I did it by making a copy of the vcvars32.bat and added a few commands like this:
cd %~dp0%
cl /LD source.cpp /EHsc ;remember putting this part after the bat-file called all important commands
Now I just need to execute this file from c++ and here we go.
I'm trying to compile a C++ program from the VS2013 command window with includes and linked libraries. Pretty standard stuff. However, Microsoft's website explaining the syntax is not very clear to me.
I'm trying the following command:
cl /EHsc program.cpp /I "\path\to\includes"
/LIBPATH:"\path\to\library\directory" /LINK libfile1.lib libfile2.lib
Note: It's all on one line when I execute it, but for readability I've split it here.
The quotes are because some of the directories in the paths have whitespace in them beyond my control (like Program Files).
I'm trying to adapt this command from a property sheet I made using the Visual Studio interface, so if it helps, the mapping I'm making is:
IncludePath --> /I
LibraryPath --> /LIBPATH:
AdditionalDependencies (under Link) --> /LINK
I am running this as an admin in the x64 Native Tools Command Prompt on a machine running 64-bit Windows 10. However, it gives me these warnings and errors:
cl: Command line warning D9002: ignoring unknown option '/LIBPATH:\path\to\library\directory'
cl: Command line warning D9002: ignoring unknown option '/LINK'
LINK : fatal error LNK1181: cannot open input file 'libfile1.lib'
Where am I going wrong?
The /link option must be lowercase and place the /LIBPATH option after it:
cl /EHsc program.cpp /I "\path\to\includes" /link /LIBPATH:"\path\to\library\directory" libfile1.lib libfile2.lib
try to add the lib's path to your Library Directories (Configuration Properties >> VC++ Directories).
and compile again
I have a c++ project in MSVS 2010 Express. I have been planning to write several unit tests to validate this project. Right now they go along the following lines:
#include "header.h" //Header is the header for the source I want to test
void testSomeFunction()
{
//Call function (from external src, prototype in header.h)
//Save output to file
}
int main()
{
testSomeFunction();
return 0;
}
I am creating these source files outside my project because I want to be able to run each of them as individual executable, but I am having trouble getting the Microsoft linker to link them.
This is my problem so far (CMD output):
cl ut_Converter.cpp Converter.obj
ut_Converter.cpp
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xlocale(323) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
/out:ut_Converter.exe
ut_Converter.obj
Converter.obj
Converter.obj : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in ut_Converter.obj
Converter.obj : fatal error LNK1313: pure module detected; cannot link with ijw/native modules
I never really use Microsoft products, I'm familiar with using the GNU tools GCC and make but I have to use the Microsoft tools for this and I have no idea how they work.
Maybe I'm going about building these tests the stupid way but it's the best way I can think of right now.
This is what I want to do:
Compile the source files in my project into object files
Compile my test files into object files
Link the test object file with the appropriate project object files to produce the test executable
How do I go about doing that? (I'm guessing there are some settings I need to set to make everything compatible but I have no idea what they are or how I would go about setting them)
Extra: I know it mentions the debug level but I'd be willing to bet that there will be other incompatible settings. Is there a way to find out what the settings are in the program so I can pass them to cl.exe when I run it?
Edit: When I say command prompt I do mean the one that comes with Visual Studio with all the environment variables setup.
Have you tried going to Programs / Microsoft Visual ... / ... Tools / ... Command Prompt, and running from that dos console window which has the environment variables setup?
During the compilation process of my application (Debug mode), I am getting the following error, related to the CRT library:
16>libcpmt.lib(stdhndlr.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in poStat.obj
According to the Microsoft MSDN topic, I need to set the runtime library to /MTd in order to append the correct library compiled with debug mode. I also have to define a _DEBUG flag - and thats exactly what I have done.
Even though I have did everything it requires to use the CRT with debug mode, its still trying to use one without the debug mode (libcpmt.lib instead of the libcpmtd.lib).
How can I fix this?
Update
When I go to the C:\Program Files\Microsoft Visual Studio 11.0\VC\lib and change the name of libcpmtd.lib to the libcpmt.lib (had to temporary remove the existing libcpmt.lib) it builds successfully in a debug mode.
As Hans Passant already pointed out, the reason you have this is because some of the .lib or .obj files you are linking were compiled with Release settings, and some with Debug. The real question for you now is how to find which libraries or object files need to be fixed. Here is one way to do this
link /dump /all "Path_To_Lib_or_Obj" | findstr /L "\/DEFAULTLIB"
This will print out all default libraries, including CRT. This command has to be executed for each .lib and .obj that appears on your linker build command. For Debug you should see something like:
/DEFAULTLIB:msvcprtd
/DEFAULTLIB:MSVCRTD
/DEFAULTLIB:OLDNAMES
...
and for Release:
/DEFAULTLIB:msvcprt
/DEFAULTLIB:MSVCRT
/DEFAULTLIB:OLDNAMES
...
I am getting a really strange linker error appearing:
link.exe : fatal error LNK1107: invalid or corrupt file: cannot read at 0x270
But this is strange, because usually the error message tells you what object is invalid or corrupt. In other words, typically this error message looks something like this:
myDLL.dll : fatal error LNK1107: ....
However, in this case, the invalid object is the application itself (link.exe) that is running!
I've tried replacing the executable with another copy that I know is valid. Same error.
The command I am running is this:
../vendor/microsoft/msdev80_2005/VC/bin/link.exe /NOLOGO /SUBSYSTEM:CONSOLE /LIB
PATH:../vendor/microsoft/msdev80_2005/VC/atlmfc/lib /LIBPATH:../vendor/microsoft
/msdev80_2005/VC/lib /LIBPATH:../vendor/microsoft/msdev80_2005/VC/PlatformSDK/Li
b /LIBPATH:lib/win32/dbg /OUT:bin/win32/dbg/bugshow.exe Advapi32.lib ws2_32.lib
bugshow/obj/win32/dbg/main.o libA.lib libB.lib libC.lib libD.lib
main.o is getting compiled using the following compiler directive:
../vendor/microsoft/msdev80_2005/VC/bin/cl.exe /nologo /X /w /EHsc -I../vendor/m
icrosoft/msdev80_2005/VC/atlmfc/include -I../vendor/microsoft/msdev80_2005/VC/in
clude -I../vendor/microsoft/msdev80_2005/VC/PlatformSDK/Include /D_WIN32 /DBOOST
_USE_WINDOWS_H /DWIN32_LEAN_AND_MEAN /D_WIN32_WINNT=0x0501 /DBOOST_THREAD_USE_LI
B /DBOOST_ALL_NO_LIB /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /Z7
/MTd /c -I../vendor/boost.org/boost/1.45.0/include /Fobugshow/obj/win32/dbg/main.o
bugshow/main.cpp
Any ideas why link.exe would be failing like this?
UPDATE:
When I add the folder that link.exe resides in to my PATH, and then call link.exe without the path prefix, I get the following error instead:
LINK: fatal error LNK1181: cannot open input file 'link.exe'
Why is link.exe trying so desperately to open itself??!?!
I figured out the problem!
There is a nasty little ENVIRONMENT variable that the MSVC linker uses (described here) on Microsoft's MSDN page. It says:
LINK, if defined, prepends arguments in the command line.
My system had the environment variable LINK defined as STATIC by a recent application I installed. This caused link.exe to interpret the command-line instantiation of itself as follows:
STATIC link.exe /NOLOGO /SUBSYSTEM:CONSOLE ...
In other words, *argv[1] which is usually the first command line parameter, was actually link.exe. It basically bumped all the arguments down by one offset. This in turn caused link.exe to try and interpret itself as its first input file!
Absolutely, unbelievably frustrating and hard to detect problem...
I read that it produces this error when you've included a header file (.h) in your Linker. I had this problem and solved it by removing the .h in Linker > Input > Addtl Dependencies