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
Related
I am trying to compile a simple program using scons + MSVC compiler under Windows. Program source is just simple "Hello world".
#include <iostream>
using namespace std;
int main() {
cout << "Hello World!\n";
return 0;
}
SConstruct is utterly simple:
Program("hw.cc")
When I run scons in the source directory, I get
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cl /Fohw.obj /c hw.cc /TP /nologo
scons: *** [hw.obj] Error 123
scons: building terminated because of errors.
in the console and pop-up message with 0xc000007b error.
Aslo results of where command:
where cl
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\Hostx86\x86\cl.exe
where scons
C:\Python35-32\Scripts\scons.bat
I don't have any clue what's wrong.
UPD
SCons debug output
UPD 2
After some experiments with cl and scons I have finally figured out what was wrong and how to fix it.
First of all, cl should be available from the command line. If after entering command cl in the console you get errors like command not found, you should add path to cl.exe to the PATH system variable. In my case
PATH=<rubbish>;C:\Microsoft\VC\Tools\MSVC\14.14.26428\bin\Hostx86\x86;
After this you should set up variables INCLUDE and LIB to tell compiler and linker where to find include files and libs. And this part is a little bit tricky, because, to my surprise, cl does not compiling anything without Windows Kits 10 (whatever it is). Thus, you should specify its includes and libs accordingly. In my case
INCLUDE=C:\Microsoft\VC\Tools\MSVC\14.14.26428\include;C:\Program Files (x86)\Windows Kits\10\Include\10.0.17134.0\ucrt
LIB=C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17134.0\ucrt\x86;C:\Microsoft\VC\Tools\MSVC\14.14.26428\lib\x86;C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17134.0\um\x86
When these variables are set up correctly, hw.cc should compile fine.
And, probably, this should do the trick for scons too, but to make one hundred percent sure it works correctly, SConstruct should be modified to something like this
import os
env = Environment(ENV = os.environ)
flags = ["/EHsc"] # Flags are completely optional
env.Program("hw.cc", CXXFLAGS=flags)
With all these steps, everything should compile fine.
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 have added some information to this question, below the line of xxxx.
I am attempting to move a large ActiveX (legacy) control from Visual C++ version 6 to Visual Studio 2010. The build went just fine under VSC++6. The automated conversion (within VS2010) seemed to run smoothly. There were a number of minor errors which had to be corrected in the code, such as having to declare variables to be integer rather than letting them default. Upon fixing the last error and building, the link step gave this error:
1>LINK : fatal error LNK1104: cannot open file '.\Debug\/.obj'
I have searched and found a couple people had asked about this problem, but the solutions were very project specific. I could find nothing that applied to my situation.
There were two projects in the original solution. To attempt to solve the problem, I separated them into two separate solutions, one of which produces a .dll and works and the other (to produce the activeX component) which fails with the above error.
I really don't know where to look.
I have no .cpp nor .h files with Debug in the filename.
There must be something telling the linker to look for this file... but where? How would I even recognize it. (I'm not even sure what the forward slash in the filename represents. Is it escaping the period... or does the pair of characters (backslash forwardslash, \ /) escape the forward slash meaning it is part of the filename?)
Where do I even start?
I think that I have heard that Visual Studio generates command lines which actually do the compilation and linking. Is there any way to see the generated command line to do the Link?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I just located 3 files with names and content as shown. They seem to be
related to the problem. The 3rd file shows the bad file name (twice). Can anyone tell me where in the Visual Studio GUI they are set up? Or what may cause the erroneous entries in the last file?
custombuild.command.1.tlog -------------------
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\QGETL32.ASM
..\Assembler\ml /Fo.\Debug\Qgetl32.obj /coff /I. /Zi /c /Cx /Ta Qgetl32.asm
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\ROT32.ASM
..\Assembler\ml /Fo.\Debug\Rot32.obj /coff /I. /Zi /c /Cx /Ta Rot32.asm
custombuild.read.1.tlog ----------------------
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\QGETL32.ASM
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\ROT32.ASM
custombuild.write.1.tlog ---------------------
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\QGETL32.ASM
C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\DEBUG\.OBJ
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\ROT32.ASM
C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\DEBUG\.OBJ
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.
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