How to fix "CL.exe" Not Compiling C++??
I have created a standalone python project on my desktop, keep in mind that I'm not using Visual Studio, I am in fact using pythontowin. I would like to compile a C++ file into a DLL to use for my python project. But I am getting weird unexplained errors when trying to compile with cl.exe.
Here is my C++ file.
#include <Windows.h>
#include <iostream>
using namespace std;
void Thread() {
cout < "Hello World" < endl;
Sleep(1000);
}
BOOL DllMain(HINSTANCE hDll,DWORD dwReason, LPVOID) {
if (dwReason == DLL_PROCESS_ATTACH) {
CreateThread(0, 0, (LPTHREAD_START_ROUTINE)Thread, 0, 0, 0);
}
return TRUE;
}
Command used for cl.exe: cl.exe /std:c++14 /LD ./../LibraryXdll.cpp
And this is the error I am getting: fatal error C1034: Windows.h: no include path set
If anyone could solve this error I would be very thankful and I can finish off my project thanks for the help. Regards RanOutOfQuestions!
Taking up on Tadman's comment:
It looks like you didn't set up your environment variables for use of cl.exe
If you have gotten cl.exe, you should also have a Bat-File called vcvarsall.bat or vcvars32.bat / vcvars64.bat. In case of a default Visual studio installation these can be found under "Program Files (x86)\Microsoft Visual Studio\version number\produkt type, e.g. community\VC\Auxiliary\Build".
Run the appropriate version of vcvars... (32 or 64 bit, or specifiy the flag for vcvarsall, see docs), and your include paths for THAT SESSION will be set (inside that terminal, if you close it the changes are lost again and you have to call vcvars again next time).
EDIT: Microsoft documentation on vcvars
You can work around that Reset by calling vcvars every time before executing the compiler, though this isn't a beautiful solution
Related
I have a strange problem with system error messages obtained from std::error_code on Windows. When I build and run test program 1 (see below) using my locally installed Visual Studio, error messages for all system error codes come out as "unknown error". On the other hand, when building and running the same program on the same version of Visual Studio through Godbolt / Compiler Explorer, proper error messages are produced (see test program 1 and output below).
I tested this with Visual Studio 2022 version 17.3.3 (MSVC 19.33) on Windows 10.
I am using the community version of Visual Studio.
I have tried to build locally using the developer command prompt (cl test.cpp), using a Visual Studio console project (all settings at default), and using a Visual Studio CMake project (all settings at default). It makes no difference. In all cases, all error messages come out as "unknown error".
I am not experienced with Visual Studio, so I may definitely be making a very basic mistake.
Any advice as to how I can further diagnose the problem is also welcome.
Output from test program 1 (see below) when built and run through Godbolt / Compiler Explorer:
message = 'The directory is not empty.' (193331629)
Output from test program 1 (see below) when built and run locally:
message = 'unknown error' (193331629)
Output from test program 2 (see below) when built and run locally:
message = 'The directory is not empty.' (193331629)
Test program 1:
#include <windows.h>
#include <system_error>
#include <stdio.h>
int main()
{
std::error_code ec(ERROR_DIR_NOT_EMPTY, std::system_category());
printf("message = '%s' (%lld)\n", ec.message().c_str(), static_cast<long long>(_MSC_FULL_VER));
}
Test program 2 (for contrast):
#include <windows.h>
#include <stdio.h>
int main()
{
char buffer[256];
DWORD len = FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, ERROR_DIR_NOT_EMPTY, 0, buffer, 255, NULL);
while (len > 0 && (buffer[len - 1] == '\n' || buffer[len - 1] == '\r'))
--len;
buffer[len] = '\0';
printf("message = '%s' (%lld)\n", buffer, static_cast<long long>(_MSC_FULL_VER));
}
Ok, the problem in my case is that the system locale is set to "en-GB" and not "en-US".
If I pass language identifier 2057 (en-GB) to FormatMessage() I get no error message, but if I pass 1033 (en-US), I do.
So far, I have not been able to change the system-level locale, but even if it can be done, it seems rather suboptimal that system error messages fail to work if my system locale is set to "en-GB".
I wonder if there is a rational idea behind this behavior, or if it is just plain broken.
In any case, the solution in my case, I think, is to introduce a custom error category that invokes FormatMessage() with a language identifier of 0 (see https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage), and then forward to the native system error categeory in the functions that deal with mapping to generic error condition.
I just installed visual studio, (not new to coding) and I keep getting an error that goes like "error: unable to open file C:user...main.obj Error code = 0x80070002"
an Image of the error
this error shows up whenever there is something wrong with my code like for example if i do:
#include <iostream>
int main()
{
std::cout << "Hello World!\n";
}
everything runs normal, but if I make a mistake say:
#include <iostream>
int main()
{
std::cout std::cout << "Hello World!\n";
}
I get the error, it's so annoying I don't want to get that error every time there is something wrong with my code the error list bar is enough, what do I do ?
Could you please tell us what version of Visual Studio are you using?
If you are using vs2017 or later, I suggest you could try to use /DEBUG:FULL property in "Linker/Debugging/Generate Debug Info.
I suggest you could refer to the Doc:
When you specify /DEBUG with no additional options, the linker
defaults to /DEBUG:FULL for command line and make file builds, for
release builds in the Visual Studio IDE, and for both debug and
release builds in Visual Studio 2015 and earlier versions. Beginning
in Visual Studio 2017, the build system in the IDE defaults to
/DEBUG:FASTLINK when you specify the /DEBUG option for debug builds.
Other defaults are unchanged to maintain backward compatibility.
Rebuild the program in a different disk or reinstall the VS could be the final solution I think.
I am trying to use Open Cv on Visual studio to write c++ code. I tried a lot of ways to reach this goal for 3 days. here is what I did in these days:
**1.download and extract open cv 4.1.1 (C:\opencv).
2.download and install Visual Microsoft Studio 2019.
3.copy the bin directory of open cv to the system variable path.
(in my case:"C:\opencv\build\x64\vc15\bin;C:\opencv\build" )
4.add include folder to the project's properties(my project name is opencv):
(properties->configuration properties ->edite include directories value to : (C:\opencv\build\include )
5.edite library directory to ( C:\opencv\build\x64\vc15\lib)
6.then in linker menu->inpute->adittional dependancies -> edit its value to "opencv_world411d.lib" .**
now I write a simple code to test open cv:
#include <iostream>
#include <opencv2/highgui/highgui.hpp>
using namespace std;
using namespace cv;
int main() {
Mat im = imread("cameraman.tiff", 0);
}
this code built correctly but when I run it It doesn't work with error :
Unhandled exception at 0x000007FEBA8D3AE2 (opencv_world411d.dll) in opencv.exe: 0xC000001D: Illegal Instruction.
gfluidimgproc_func.simd.hpp not found
You need to find gfluidimgproc_func.simd.hpp to view the source for the current call stack frame
"I added screenshot"
error report
also, I tried Cmake too.
first, configure and generate OpenCV's source file.
second, open the project in Microsoft visual studio and build all
then I build the install folder.all has been done successfully.
questions:
1.how can I fix this error to run OpenCV on Microsoft visual studio 2019 ?
does Microsoft visual studio 2019 support open cv 4.1.1? have you tried it?
tanks for your attention.
my operation system is: windows 7
intel core i5
>>4.add include folder to the project's properties(my project name is opencv): (properties->configuration properties ->edite include directories value to : (C:\opencv\build\x64 )
This is wrong, you should add C:\opencv\build\include and C:\opencv\build\include\opencv2 to the include directories in your case.
I test your case on My PC, I use VS2019 and OpenCV4.1.1 to make a test. Your other steps are correct. This step will cause the header file not to be found, so the corresponding function can not be identified and will be displayed as illegal instructions.
I have the same problem and from what I understand it is because we compile in x64 bit and execute it on an old CPU which doesn't support sse3 instructions (in my case an old i5 750). I believe your only solution is to recompile OpenCV either in 32bit or in 64bit with sse3 disabled.
Recently my gnu makefile stopped linking my C++ project. I had made some changes. I have copied the link line out and run it from a batch file. It builds fine. But the same line strangely fails when I run make. The error it gives is:
LINK : fatal error LNK1181: cannot open input file 'user32.lib'
which has to be a red herring because from the same command line prompt, running the link command succeeds. I am beginning to suspect GNU make. This used to work from within make but I made a few additions and changes to the makefile to get it building on Linux which seemed to introduce the problem.
I am using :
GNU Make 3.80
MS Visual C++ Linker 10.00.40219.01
on Windows XP.
My LIB and LIBPATH both include the path to the SDK directory which contains the libraries. My link command is as follows:
link C:\SDL-1.2.14\lib\SDL.lib C:\SDL-1.2.14\lib\SDLmain.lib C:\SDL-1.2.14\lib\SDL_image.lib C:\SDL-1.2.14\lib\SDL_ttf.lib C:\SDL-1.2.14\lib\SDL_mixer.lib C:\SDL-1.2.14\lib\SDL_net.lib ../../build/lib/sdlhal.lib user32.lib gdi32.lib kernel32.lib oldnames.lib wsock32.lib advapi32.lib comdlg32.lib comctl32.lib wsock32.lib winmm.lib netapi32.lib OpenGL32.lib glu32.lib /nologo /incremental:no -subsystem:console /PDB:../../build/bin/Prog.pdb /OUT:../../build/bin/Prog.exe /MAP:../../build/bin/Prog.map ../../build/Prog/intr/util.obj ../../build/Prog/intr/objwithvel.obj ../../build/Prog/intr/rock.obj ../../build/Prog/intr/explosion.obj ../../build/Prog/intr/ship.obj ../../build/Prog/intr/photon.obj ../../build/Prog/intr/world.obj ../../build/Prog/intr/test.obj ../../build/Prog/intr/main.obj
EDIT: Bit of progress with C++ program below. My Environment variables were:
LIB=C:\Program Files\Microsoft Visual Studio 10.0\VC\LIB;C:\Program Files\Microsoft Visual Studio 10.0\VC\ATLMFC\LIB;C:\Program Files\Microsoft SDKs\Windows\v7.0A\lib;
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\Program Files\Microsoft Visual Studio 10.0\VC\LIB;C:\Program Files\Microsoft Visual Studio 10.0\VC\ATLMFC\LIB;
But when printed out by program run from within make, they are:
LIB=.lib
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\WINDOWS\Microsoft.NETFramework\v3.5;C:\Program Files\Microsoft Visual Studio 10.0\VC\LIB;C:\Program Files\Microsoft Visual Studio 10.0\VC\ATLMFC\LIB;
Based on your description of the value of LIB, I suspect that you have simply set the "LIB" variable in your makefile (to ".lib"). In standard GNU make (actually, all versions of make) all the environment variables are imported into make as make variables when make starts up (there are exceptions, such as SHELL, which are handled differently).
Whenever make invokes a command, all the current values of variables that were imported are written out to the environment of the child process.
Put another way, any variable that make read from its environment is considered to be marked for export when make runs any command from a recipe.
So if you have a makefile like this:
LIB = .lib
all: ; #echo "LIB = %LIB%"
and you run it like this:
> set LIB=C:\foo;C:\bar
> make
then the output will be "LIB = .lib", not "LIB = C:\foo;C:\bar"
I suspect that your LIB and LIBPATH variables aren't set the way you think they are when link is invoked from make.
Try creating your own link.exe program that gets invoked from make and dumps the command line and environment. That'll tell you for certain whether or not the variables are set correctly by the makefile.
#include <stdlib.h>
#include <stdio.h>
int main( int argc, char** argv, char** env)
{
int i = 0;
for (i = 0; i < argc; ++i, ++argv) {
if (!(*argv)) {
*argv = "(null)";
}
printf( "arg[%d]: \"%s\"\n", i, *argv);
}
puts("\nENVIRONMENT...\n");
while (*env) {
printf( "%s\n", *env);
++env;
}
return 0;
}
Also check that there aren't unquoted spaces in the wrong place in the link command line. While it would seem to be unrelated to the error you mention in the question (and is probably really just a cut/paste error), the link command line you gave has a space in the middle of the path/file name for explosion.obj.
This is likely to be a path issue. Are you using the mingw version of GNU make, or the Cygwin version?
One way to debug this is to put an echo $LIB and echo $LIBPATH command into the make recipe to confirm that these are getting set as you expect.
I installed CodeBlocks 10.5 with minGW compiler. After setting environment variables for minGW I cheked gcc -v on cmd and it is working fine.
The problem is that, I have made a small program in CodeBlocks project the code is below
#include <iostream>
#include <allegro5/allegro.h>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
return 0;
}
There is an error, the build log is:
Compiling: main.cpp
C:\Program Files\CodeBlocks\MinGW\bin\allegro_pract… error: allegro5/allegro.h: No such file or directory
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings
Directory structure for codeblocks is:
C:\Program Files\CodeBlocks
and for minGW:
C:\Program Files\CodeBlocks\mingw
and my project is:
C:\Program Files\CodeBlocks\bin\
i am confused about allegro library where to place it.. as I have not used any external library..
the library is placed now at:
C:\Program Files\CodeBlocks\mingw\allegro\
I am "Googling" for a long time but no tutorial seems to be working..
please give a valid solution.. and where to place allegro library..??
Do not try to "place" libraries in the "right place". Instead, tell the IDE where you put them explicitly. This is called setting the include path.
Code::Blocks should have some setting for include directories. You should point it to the place where Allegro lives.
Set up your IDE to look for Allegro:
(source: allegro.cc)
The complete tutorial is here:
http://wiki.allegro.cc/index.php?title=Windows,_Code::Blocks_10.05_and_Allegro_5
http://www.mingw.org/wiki/IncludePathHOWTO:
The actual search path, for any specific installation of MinGW may be determined, by running the compiler itself, with the "-v" option; typically, for a GCC-3.4.5 installation in c:/mingw:--
defaults appear to be:
c:/mingw/include/c++/3.4.5
c:/mingw/include/c++/3.4.5/mingw32
c:/mingw/include/c++/3.4.5/backward
c:/mingw/include
c:/mingw/lib/gcc/mingw32/3.4.5/include
I don't use mingw, so, read the link.