I am running windows 8 x64. I have just installed the GNU C++ compiler through MinGW.
When I try to test this in the command line I get:
g++ is not recognized as an internal or external command
If I change to the directory c:/MinGW/bin and run g++ it works.
I have set the path to c:/MinGW/bin. This appears when I enter echo %path% and I have tried restarting my computer after changing the path variable.
I've searched the internet and the advice I've gotten back is change the path variable. I have done this and I am looking for a different solution to this problem.
Related
I am trying to install slycot and I get the following issue.
The CMAKE_C_COMPILER: cl is not a full path and was not found in the PATH.
To use the NMake generator with Visual C++, cmake must be run from a shell
that can use the compiler cl from the command line. This environment is
unable to invoke the cl compiler. To fix this problem, run cmake from the
Visual Studio Command Prompt (vcvarsall.bat).
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH
I downloaded Visual Studio 2019. I tried to run "CMake" from a VS command prompt, but nothing happens.
I have found the vcvarsall.bat file location in the VS folder, but I do not know what to do with it. Would anyone be so kind to tell me what to do next? (I am new to scripting, so please be explicit).
Thanks
Normally cmake uses the program vswhere.exe to detect your VS2019 installation. But sometimes this seems not to work.
You can run the
vcvarsall.bat Win64
to setup the environment variables in the command prompt. How to find the path to it can be found here. And I am pretty sure the script vcvarsall.bat will show you the option when calling it without a parameter.
I'm trying to use CppUTest in Windows, first step is to get it to work and I already have problems. These are the things I've tried:
First Approach
With CMake, using the cmake GUI I can do the configure and generate command and I get something in the output directory, but no binaries and no libraries, just a bunch of cmakefiles. The CMake GUI says everything went OK during the configuration and generation steps, however the libraries (.lib files) are not generated in the output directory... is there something I am missing? I've never used CMake before.
Second approach
With MinGW and msys alone, running cmd in Windows and executing a MinGW shell by typing sh in the Windows terminal, afterwards I execute the following commands:
cd <CppUTest folder>
mount c:\mingw /mingw
./autogen.sh
./configure
make
The build process starts but it fails with a message indicating that pthread.h was not found in MinGW directory. If I install the pthread-win32 package with the MinGW package manager and repeat the same steps as above the build process starts but fails with a message indicating that the structure timespec is defined in time.h and pthread.h.
I've tried to follow this same procedure with CppUTest 3.6 and it works perfectly fine, I get the .lib files, so I guess I will have to continue with this for now.
Does anyone know how to build CppUTest 3.7 (latest release) with MinGW or CMake?
In the end I used Cygwin to compile it, I couldn't find a way to compile it with MinGW properly, I added a dirty trick to make it compile under MinGW (handled the timespec redifinition) but chances are that is going to cause issues.
Just make sure that you use Cygwin aswell to compile your tests, something that I found out after making this question (https://www.youtube.com/watch?v=oVmd0P85D8o).
I have a strange problem with MinGw installation (on Win 8 PC). The compiler works for both fortran:
gfortran hw.f -o hw.exe
and for C++:
g++ hwc.cpp -o hwc.exe
However, no exe files are created. The compiler exits without option but there is just no EXE !?
When I make (intentionally) an error in the source, I have proper error message, so compiler
undoubtedly work. I tried using -v switch to see the flow and I see no suspicious messages as well.
So - what's the heck? :-)
Check "quarantined items" in your anti-virus software. I used to have similar problem with MinGW on XP+avast when I tried to build wxWidgets (2.8.x I think) - during the "configure" stage avast moved some (but not all) executables produced by configure script into "quarantined items folder".
I've tried official howto but failed. I got error:
"The procedure entry point InterlockedCompareExchange#12 could not be located in the dynamic link library libstdc++-6.dll"
The problem was due the old gcc compiler, bundled with DevKit from rubyinstaller.org (4.5 vs 4.8 on my PC). Use MSYS instead. Assume we have zeromq source inside D:\libs\zeromq, then the procedure is:
Download GUI MinGW installer.
Install base and MSYS (if you already have working gcc compiler you probably only need MSYS).
Launch MSYS environment by executing C:\MinGW\msys\1.0\msys.bat.
Follow Using MSYS with MinGW section:
mount c:/mingw /mingw
cd /d/libs/zeromq
./configure --prefix=/mingw
make
Copy /d/libs/zeromq/src/.libs/libzmq.dll to your desired place.
In fact I needed to use ZeroMQ with C++, so I downloaded zmq.hpp, moved it to include directory, and compiled hwserver.cpp to test it:
C:\MinGW\bin\g++.exe -o hwserver hwserver.cpp -L. -lzmq -ID:\libs\zeromq\include
It worked, but when I launch it I got:
Assertion failed!
Program: D:\tmp\zmq\hwserver.exe
File: D:\libs\zeromq\include/zmq.hpp, Line 280
Expression: rc == 0
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I've managed to get rid of this failure by commenting lines 279, 280. Similar issue
I just installed cygwin on a new Windows box running Windows 7 and I am getting funny behavior when I compile a c++ program. Here's what I type:
g++ test.gpp -o test
On my other Windows boxes, this creates an exe file, test.exe, and it is, of course an executable. But on this installation, the file test is created. To my surprise, it is not an executable, but rather looks like a debug file (in ascii printables). If I instead type:
g++ test.gpp -o test.exe
Then I do get the executable test.exe. (1) why in all my other implementations do I get the executable, but not with this most recent attempt? (2) Why do I care? Well, I also work on linux boxes and am not accustomed to typing the extension ".exe". (I hate that aspect of non-linux files!) I am guessing that there is some sort of one-time flag I can set to make the default file that g++ creates be a .exe file.
The problem with this problem is that none of you may be able to reproduce it! (I can't on my other machines!)
As far as I can tell, g++ doesn't recognize the .gpp extension. Rename the file from test.gpp to test.cpp and try again.
On my Cygwin system, g++ test.gpp gives me an error message:
... file format not recognized; treating as linker script ...
Cygwin compilers do create executable files with a .exe extension (because Windows requires it), but it also lets you refer to such files without the suffix. So, for example:
ls -l test.exe
and
ls -l test
should both show you the same file. (If you happen to have files with both names, things can get a bit confusing -- so don't do that.) g++'s -s option also treats the .exe suffix specially, so -o test and -o test.exe should do the same thing.
I don't know why you're seeing the behavior you describe. Perhaps you happen to have something in test.gpp that looks like a valid linker script?
g++ test.gpp -o test
This should create a file called test (with no extension). If that file is created than give executable permission the file using chmod +x test
than use ./test to run it. see if it works.