I installed MinGW and set the variable PATH. Then g++ in the terminal worked only ONCE, then the terminal does not recognize g++ only gcc, as you can see:
I tried to reinstall it, but it did not work. Still the g++.exe file is missing.
And when I try to install it, the terminal says I already installed it, like this:
Just type echo $PATH then you should have your g++ executable file on that path.
I already have the solution, my antivirus deleted g++.exe very time when i installed it.
Related
So I tried to check Mingw-w64 tools are correctly installed and gcc, g++ were correctly installed but gdb wasn't. I'm planning to usE Visual studio code in windows 10.
In the https://code.visualstudio.com/docs/cpp/config-mingw#_run-helloworldcpp, it said to match PATH entry but when I went to C:\msys64\mingw64\bin directory, the file was empty. Did I miss something or how do I know the correct path to put in the environment variable?
I tried C:\msys64\mingw64\bin as both user variable & system variable path but it won't work. and it said command not found.
This is what it said.
$ gdb --version
bash: gdb: command not found
Try installing GDB by running this in your Bash shell:
pacman -S $MINGW_PACKAGE_PREFIX-gdb
I was trying to compile a .cpp file using command-line, but I am encountering an error.
I have installed MinGW properly from the official installer.
Also, I sat the path to the bin folder of MinGW which is in C drive.
Now when I try to compile file with command:
g++ demo.cpp -o demo.exe
I get a "CC1plus.exe - System error" message-box, like:
The code execution cannot proceed because libisl-21.dll was not found.
Reinstalling the program may fix this problem.
I can't find the .dll file anywhere. What seems to be going wrong? Any lead? I have reinstalled MinGW multiple times.
Thanks,
libisl-*.dll is part of the MinGW-w64 distribution.
I'm not sure older MinGW also provides it, but you should use MinGW-w64 anyway (e.g. from https://winlibs.com/ or installed via MSYS2's pacman) as it's much better maintained and supports newer Windows versions (including 64-bit).
Your problem is that g++.exe depends on libisl-21.dll but can't find it.
Check the following:
From which location is g++.exe being called? This should be the first location containing g++.exe in the PATH environment variable in the environment where you were running g++.exe from (e.g. if this is the Command Prompt type ECHO %PATH% to see its value).
Does the folder containing g++.exe also contain libisl-21.dll?
Is your MinGW setup broken or can it be uninstalled+reinstalled?
Do you have multiple MinGW / MinGW-w64 installations on your system that are getting mixed up (e.g. because multiple are point to via the PATH environment variable)?
You can try to unpack a standalone MinGW-w64 from https://winlibs.com/ - which doesn't have an installer and will not interfere with your other installed MinGW(-w64) releases - and try to use g++.exe from its bin folder by specifying it's entire path.
I'm working on an embedded program, but want to test out code snippets on g++ on Windows because it's much faster than building & loading on the embedded system itself. Our embedded system's unittests run on C:\MinGW\bin\gcc\g++.exe, so that's the copy of g++ I was trying to use when I had this problem. Using hints from Brecht Sanders's answer, this solved my problem:
In a "build.bat" file I created local to my code snippet "ftest.cpp" file:
#setlocal
#set ORIGINAL_PATH_VARIABLE=%PATH%
#set PATH=C:\MinGW\bin;C:\MinGW\bin\gcc;%ORIGINAL_PATH_VARIABLE%
g++ -std=gnu++11 -g -Wall -Werror ftest.cpp
(I searched for and found libisl-21.dll at C:\MinGW\bin.)
Hopefully someone finds this helpful.
I am not sure if I should delete the X Code as it takes a lot of space on MacBook. I want to use g++ compiler for compiling my c++ program.
It is possible to install just the Xcode command line tools. Open Terminal and execute xcode-select --install. This will get you your compiler (clang, not g++. g++ is just an alias for clang++ on Macs), linker, make, etc.
To actually answer your question, yes. If you install something and then uninstall it, the stuff that got installed will get uninstalled.
If you want the actual g++ compiler, you will need to install it yourself, homebrew is the easiest way. The gcc package will create versioned symlinks for you (g++-9), and you can just use that, or create another symlink that redirects g++ to g++-9. If you did that, you'll have to remember to manually update that symlink when the major version changes. All this is found in usr/local/bin after installing homebrew and the gcc package.
I know about this question: macOS 'wchar.h' File Not Found
but it did not help me. I've tried reinstalling xcode, reinstalling command line tools, restarting the system. wchar.h file is in place, but the compiler does not manage to find it. What else could I try? Maybe it is sysroot related? Any way to fix that?
macbooks-MacBook-Pro:Rack euphorbium$ sudo make
c++ -Iinclude -Idep/include -Idep/lib/libzip/include -DVERSION=dev -MMD -O3 -march=core2 -ffast-math -g -Wall -DARCH_MAC -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.7 -DAPPLE -stdlib=libc++ -std=c++11 -stdlib=libc++ -c -o build/src/app.cpp.o src/app.cpp
clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk' [-Wmissing-sysroot]
In file included from src/app.cpp:1:
In file included from include/app.hpp:2:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/vector:265:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:90:
/Library/Developer/CommandLineTools/usr/include/c++/v1/wchar.h:119:15: fatal error:
'wchar.h' file not found
#include_next <wchar.h>
^~~~~~~~~
1 error generated.
make: *** [build/src/app.cpp.o] Error 1
since wchar.h exists both in the xcode app, and in the /Library/Developer/CommandLineTools I think that it looks for it in some completely unrelated folder.
I had the same problem after upgrading to macOS High Sierra. A project which was compiling before stopped working with this error. In my case, the project files had been generated by the CMake application. The solution was to run CMake, 'Delete Cache', and 'Configure' the project again. This corrected the sysroot directory reference in the make files to point to the new SDK and the error was resolved.
I've got the same problem. I was able to fix it by using a symbolic link.
This is what I made :
cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
sudo ln -s MacOSX.sdk MacOSX10.07.sdk
Then enter your root password.
NB: you have to adapt the last line with required sdk.
For any one struggling with this on MacOSX Mojave this answer solves it. In short:
Go to the terminal and run open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg This will bring up the prompt to install Xcode tools.
After that's done got to the terminal and run sudo xcode-select -s /Library/Developer/CommandLineTools
My system is macOS Mojave, and I've fixed this problem by running this command line:
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
It was caused by incorrect sysroot, (set for an older mac os version) set in makefiles.
If you are using CLion, follow these steps :
Click on CMake at the bottom center of your IDE
Click on the Settings Gear Icon at the left
Click on Reset Cache and Reload Project
Took me 3 hours to find this solution.
FYI this project was running fine on Bug Sur 11.3 but failed to build after I upgraded to Big Sur 11.4
Set an environment variable
SDKROOT="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk"
and reopen Terminal. This solves the header not found issue.
To see where the compiler finds headers, run with -v
clang -v test.c
For my case, this problem result from that MacOS changes the headers's path.
Check this note: MacOS release note.
So the solution is to make the compiler can find those headers.
My macOS version is Catalina 10.15, and XCode Version 12.4. For this version, it seems that /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg is not provided anymore and thus the sulotions above do not work for me.
This method saved my night: Fixing C++ compilation bugs for the MacOS Catalina upgrade. Note that if you follow its steps and errors that some global symbols are not found arise, do not modify the LIBRARY_PATH as it says.
I did something dumb but it did fix the problem... Not sure if it will work for your computer though.
Here is what I did:
I originally installed c++ using Homebrew on my MacBook on Mojave... so I had to manually install the Xcode CommandLineTools using the installer found at /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg . Then I copied the "c++" folder contents from to folder /Library/Developer/CommandLineTools/usr/include/c++/v1 to the folder where I want the missing file to be, at /usr/local/Cellar/gcc/8.2.0/include/c++/8.2.0 , while replacing files with the same names.
The trick worked, since now the missing file "wchar.h" is right where it should be... Your settings is probably not the same, however, I am afraid.
I'm trying to compile a simple helloworld program with MinGW on Windows and nothing happens. No output, no executable, nothing. I've just installed the latest MinGW with their mingw-get-inst-20120421.exe installer. When I use an older version of MinGW that came with Code::Blocks, I am able to compile the program. I'm out of ideas and my googling has been in vain. C:\MinGW\bin is on my path and I'm using MSYS.
Command line parameters in MSYS:
gcc helloworld.c -o helloworld
Execute the console from the Start menu, Start->MingW->MinGW Shell or from filesystem:
C:\MinGW\msys\1.0\msys.bat
Execute gcc in this shell.
Otherwise you will have to add the minGW/bin directory to your PATH environment variable.
Go to the directory where you have you gcc executable. In my case it's:
C:\MingW\bin
From there execute gcc:
gcc myFile.c
If it compiles, than something must screwed up your $PATH