I don't know if this question would fit better on superuser.com, but since it's rather compiler related, I give it a try here.
I have to use Qt with a specific version of gcc (4.5). I downloaded the last official Qt release for Windows (Vista, 32 bits version) and didn't install the shipped MinGW version; I just installed the Qt libraries/binaries.
In a console, when I type qmake && make, make fails, complaining that 'g++' is not recognized as an internal command.
If I type g++ in the same console, I however have the following output:
g++: no input files
So g++ is definitely recognized.
For those who may ask, both the Qt binaries directory and MinGW binaries directory are in the system PATH environment variable.
What could be wrong here ?
The "not an internal command" message is not one you would get if the g++ executable simply could not be found. For example, this makefile:
foo:
zz foo.cpp
gives the error:
make: zz: Command not found
when the zz executabe does not exist. I don't know what is meant by an "internal command", but I think you need to post the part of the makefile tat causes the problem. Oh, and check that you are actually using GNU make.
Related
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.
So I just recently downloaded a C++ IDE called Code::Blocks and made a new project. But when I tried to Build and Run it, the code gave some errors. I know that it isn't a problem with syntax or anything like that because I ran the default code that Code::Blocks provided. The error is the following:
Project/Target: "firstcpp - Debug":
The compiler's setup (GNU GCC Compiler) is invalid, so Code::Blocks cannot find/run the compiler.
Probably the toolchain path within the compiler options is not setup correctly?!
Do you have a compiler installed?
Goto "Settings->Compiler...->Global compiler settings->GNU GCC Compiler->Toolchain executables" and fix the compiler's setup.
Tried to run compiler executable 'C:\MinGW/bin/gcc.exe', but failed!
Skipping...
Nothing to be done (all items are up-to-date).
It seems to me like there is some kind of issue with the C++ compiler, but I thought Code::Blocks already came with a C++ compiler, so I'm not too sure what the issue here. I also followed their instructions to go to Settings->Compiler...->Global compiler settings->GNU GCC Compiler->Toolchain executables, but I'm not too sure what they mean by fix the compiler. Here is a screenshot of what I'm seeing:
Also here's info on my PC if you need it:
At this point I'm not too sure what to do to fix this problem. I have asked my friends about this problem(they have already successfully downloaded and used Code::Blocks), and they said that they never encountered this problem while they were installing it.
You need to ensure that you have a working installation of the GNU Compiler Collection, and that the paths you select for your toolchain exist.
If you don't already have GCC Installed, the easiest way would be to download a Code::Blocks distribution that comes pre-bundled with MinGW from the download site. However, it's also possible for you to install GCC through other means, such as:
Installing GCC with MinGW through msys2, or
Installing GCC with scoop install gcc on Windows
In either case, you need to select the installation path that contains the bin directory when setting up the toolchain in Code::Blocks.
In case you didn't notice, C::B formed the path to compiler with both "\" back slashes and "/" slashes, which simply isn't a valid Windows path !!
Slashes are used in Linux not Windows! But for some reason C::B is not getting this. And probably your Mingw is well set !!
C:\MinGW/bin/gcc.exe should be C:\MinGW\bin\gcc.exe
I had pretty hard time trying to fix this in win 7 32 bit/C::B version 20.03 but with no success, i checked all available options and settings, and actually i started to think that it's a bug.
(this question similar to this one but is not the same)
I'm using QtCreator on Windows platform, usually with vc toolchain.
sometimes with MinGW-W64, so for now, I'd like to try clang for some reasons.
unlike the post above - I don't use Qt library , just qtcreator as IDE, so I suppose I don't need to re-build it and QtCreator for a using clang kit, is it correct?
there are a few questions about that:
CLang distribution doesn't contain platform or even c/c++ runtime library, should i use it from vc kit? or/and MinGW runtime? how to switch between?
Correct my understanding please if it's wrong - for Win platform, clang has two options to use: 1) normal use - clang.exe ,as on any other platform 2) clang-cl.exe - additional layer which "looks like" cl.exe, and just parses cl command line keys and calls normal clang.
as I understand there is no LLDB for Windows platform , can I use GDB or CDB depends of the used runtime lib and binary format of the executable?
and finally - how to configure all this in qtcreator?
The following steps apply only to MSYS2 64-bit installation of QT Creator 4.5.1 (install instructions here), where you also have MinGW-w64 and mingw32-make installed on MSYS2; and you are building a non-QT C or C++ application.
These instructions use QMake, because QBS doesn't support MSYS2 clang. Well, QMake doesn't support it either, but I did figure out how to add support to QMake and I didn't figure out QBS.
There is QMake support for MSVC-clang but it outputs MSVC makefiles, so you can't build it with MSYS2 make. So that does not apply to us.
Install clang with pacman. I used pacman -Ss mingw-w64-x86_64-clang, your flavour may vary.
Add support for clang to QMake:
In the MSYS2 shell, go into /msys64/mingw64/share/qt5/mkspecs/
Do cp -a win32-g++ win32-clang-msys
Edit win32-clang-msys/qmake.conf and change gcc to clang, and g++ to clang++ (2 places each)
In the same file, take out -fno-keep-inline-dllexport -mthreads which are not supported by clang.
In QT Creator, set up a new Kit:
Go to Manage Kits.
Add a Custom Compiler for C and browse to the installed path (/mingw64/bin/clang.exe under your MSYS2 install).
Add a Custom Compiler for C++ as clang++.exe in the same place)
Add a manual Kit called Clang and set those two compilers as its compilers.
In the manual kit config set "Qt mkspec" as win32-clang-msys
Set "QT Version" to something. Even though I am using a non-QT project, the IDE doesn't like using the kit if "Qt version" is set to None.
Now you can attempt to build your project with the Clang kit and QMake.
I initially tried with QBS and the build failed due to this bug . But the build commands do succeed if I copy-paste them and cut out the bogus -target switch. So for QBS users I guess you have to switch to QMake in the meantime until they fix that bug.
Troubleshooting: I sometimes got an error Project ERROR: failed to parse default search paths from compiler output. This is a problem with QMake's lack of support for clang. The error tended to not occur if I built in a subdirectory of the .pro file, but did occur if I built in a sibling directory.
As a workaround: go back into win32-clang-msys/qmake.conf. Change the first clang back to g++. Then "Run Qmake" (from QT creator or commandline), then change it back. The first time you run QMake it writes the file .qmake.stash and then does not need to generate it again. The contents of this file were bogus for me but building seemed to work anyway.
Undefined references: I found that linking with -static produced a bunch of undefined references to __imp__cxa_ names. Not sure what the problem is here but maybe related to the bug with generating .qmake.stash. I guess the Qt developers would need to officially add non-MSVC Clang support to QMake.
Multiple definitions: The CLang linker gave multiple definitions for inline DLLexport functions. I found no workaround yet for this; g++ has -fno-keep-inline-dllexport to avoid this problem but CLang 5 does not support that flag.
First of all, I know that this question already exists multiple times in Stackoverflow but the answers provided for all of them didn't solve my issue(See section "Solutions worked for others" at the end of this question).
I am using the Eclipse IDE(Juno) with CDT plugin and Cygwin installed in my Windows-7 64-bit platform.
I successfully compiled and run the Hello World 'C' program but the Hello World "C++ program" is having Launch failed. Binary not found error.
I am also having recipe for target project.exe failed error in my auto-generated makefile.
Error line in makefile: #echo 'Building target: $#'
Additionally:
In c/c++ build -> toolchain editor ->
Current toolchain : Cygwin GCC
Current Builder : Gnu Make Builder
Used Tools:
GCC Assembler,
GCC Archiver,
Cygwin C++ Compiler,
Cygwin C Compiler,
Cygwin C Linker,
Cygwin C++ Linker.
When I change Current Builder from "Gnu Make Builder" to "CDT Internal Builder" the recipe for target project.exe failed error disappears but the Launch failed. Binary not found error still exists.
And also I dont have MinGW installed.
Solutions worked for others :
Before running the project directly using the run command, first Build the project and then run.
I build the project every time before I run it.
Eclipse can't find or point to an .exe file but the exe file runs fine when run from windows explorer and the answer to it is add -arch i386 to miscellaneous under linker.
My build runs without error but not creating the exe file. So this doesnt apply to me
Project->Properties->C/C++ Build->Settings->Binary Parsers
set "Cygwin PE Parser" and/or " PE Window Parser" and alike.
Tried all of them with different combinations but did not work
I also did :
adding the cygwin install dir to the path variable
added all the includes folders needed for cygwin for both GNU C and GNU C++ in Paths-and-Symbols -> includes
Saved the project before building and then running
restarted eclipse again
checked if g++ is installed using which g++ in terminal
and so on.
What could be a fix to this problem? Or do I have to install MinGW (I tried already to install MinGW with the installer.exe they provided and it failed on downloading the files several times) and try again.
I couldn't find the solution. Please show me what am I missing here.
Thanks in advance.
I just downloaded and installed Qt Creator.
I have not messed with the PATH or any other settings.
But when I try to run a Qt GUI Application project, it gives the following error:
cc1plus.exe:-1: error: error: unrecognized command line option "-fno-keep-inline-dllexport"
The output says:
Error while building/deploying project ProjectFirst (kit: Desktop Qt
5.0.1 MinGW 32bit) When executing step 'Make'
I don't understand why this is happening. I looked it up online a lot before asking, but couldn't find anything.
I've just found the problem on my friend's computer the same as yours.
Type g++ --version to see what g++ is taking by default from your path.
If it is 4.4.* (<= 4.7.2) then found that old g++ and remove it to the trash.
Usually it goes with Perl package, needed by Qt configure.
Then return to Console and try g++ --version again
if it not 4.7.2 then lookfor old g++ again and remove it.
If it is written g++ : command not found or something like that - change your PATH variable.
Don't forget to reboot your computer after changing it.
When you got g++ --version with 4.7.2, look forward to having success.
Try to use nmake, not mingw32-make
The problem is that you are using the wrong mingw32 installation (an older version).
In order to solve this, check that the Kit you use has detected the correct Mingw version (this should be 4.7, which is located inside the qt installation tools directory).