I am trying to use GDB to debug a C++ program, but my system is not recognizing gdb as a command. I installed it, along with many other tools, via MinGW. I have not had any problem with the other features I have used (gcc, g++), so the issue doesn't seem to be with my general set up. I have added the MinGW\bin directory to my PATH. The gdb.exe is in that folder. But it will not run when invoked from my project directory, it simply errors: "'gdb' is not recognized as an internal or external command, operable program, or batch file." Is there some step in setup or invocation that I missed for using GDB?
EDIT: Alright, I think I found the problem: there are two MinGW directories in my PATH, one at C:\MinGW, and another in folder that got installed with some Haskell compilers I used a while ago. It appears to be defaulting to the Haskell folder, perhaps because this directory is listed first. However, this folder contains gcc and g++, but NOT gdb. I was able to get the gdb command working by creating the fstab file in the msys directory, a step I apparently forgot when setting up MinGW. I added my C:\MinGW directory to it, and now the gdb command is working properly! Out of curiosity, what does this file do?
Also, ideally I would like it to look in the C:\MinGW directory first, since this is the folder I plan to keep updated, and the one that contains ALL of the various applications. However, the Haskell directory is specified via the system PATH variable, which I've read it's not a good idea to touch. Would switching the order that they appear even fix my problem?
EDIT 2: Not 100% sure what happened, but the gdb command appears to be working now. I have always been using the Windows cmd prompt to run these tools, so per the answer below (that I should not need to mess with msys) I deleted the fstab file, and lo, it still works! However, my second question above still stands: What is the best way to get the compilers to run out of C:\MinGW\bin instead of C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin? Is moving the Haskell location out of the system PATH and to the end of the user PATH a viable option?
I had to run pacman -S mingw-w64-x86_64-gdb separately and then gdb showed up in the bin.
You do not have to run gdb (or gcc and all other MinGW tools for that matter) within msys - it is not like Cygwin in that respect. Had you run it from the Windows cmd console, it should work.
The msys shell is useful for running configure scripts generated by Autoconf used by many Linux originated open source projects, but its environment is independent of the Windows environment.
Related
I'm following this tutorial by vscode to install a C++ compiler on Windows. Right now, I'm trying to edit C:\msys64\mingw64\bin to environment variables and save MinGW to path. I clicked OK multiple times but seems like it can't save. I also entered g++ --version and gdb --version to check for installation. It just shows "'g++' is not recognized as an internal or external command,
operable program or batch file."
If reinstalling MinGW doesn't work, add MinGW to PATH manually by this:
Find your computer's property, and then go to Advanced.
Click Alt+N
Find PATH in the box below.
Add the path of your MinGW compiler to it.
Note: Add the BIN folder.
If adding the BIN folder doesn't work, add the BIN folder in the folder under C:\msys64\mingw64 that has a long name like this:
x86_64-w64-mingw32
or whatever your folder is named.
IMPORTANT NOTE: REMEMBER TO RESTART YOUR COMPUTER AFTER DOING THIS.
I have a cmake project that successfully builds locally but errors with
include could not find load file:
CmakeDependentOption
when trying to build on a CI platform or in Docker. Note that CMakeDependentOption.cmake is a script that comes with cmake itself. So it should just be available. On CI to install cmake, I wget the relevant cmake release from their downloads page, unzip it and add the bin directory to the PATH environment variable. Then I use the cmake command to build my library. The result is the above error.
I suspect this means that a CMake variable (such as "CMAKE_MODULE_PATH" but not, since this variable seems to be empty at the start of the cmake script) is messed up or not set somehow. The path to the correct file to include is
<cmake_root>/share/cmake-3.18/Modules/CMakeDependentOption.cmake
And I have verified that it exists manually. My question: is there a way to locate this directory from within cmake? Perhaps a cmake --config or cmake --libs mode (a bit like pkg-config?)
Failing that, does anybody have any suggestions as to why this is happening and how to get around it.
You can locally because most likely you don't use a linux based platform, like windows or mac. This is because linux filesystem are case sensitive. Which means CmakeDependentOption is different from CMakeDependentOption.
Docker runs containers in linux, so filenames are gonna be case sensitive, and the include is going to fail if the cases are different.
So I want to install the dxflibn (it allows for the program to read and write .dxf files). You can find the files here. I found, on there site, this Programmer's guide. If you go to page 3, it says how to install the library. It says to use cygwin and MinGW32. I have not used this tools before so need some help.
From what I read (when I was researching these tools), the MinGW32 is used to install the compiler needed and the Cygwin can emulate the Unix system. I do have some experience with Unix command line but limited.
Back to the instruction on page 3, it says to run two commands. The first command is for executable but from the file I downloaded (the dxflib zip) there is no "configure" file to execute. While searching even more, I found the the .pro file that is in the folder of the library can produce a make file but not sure how.
Questions:
What exactly do I need to do to install the dxflib?
After I install it, for me to run it from my C++ code, what do I need to do? I read here that I need to:
A) put the header files in a location which your compiler is aware of
B) put the dll files in a location which your linker is aware of.
Any help would be amazing, tnx :)
I was able to find a solution after all.
For question 1:
I first went and installed qmake (from the Qt website).
After that, I needed to include in my "system parameters" the qmake.exe so I can run it from the Command Prompt line (like it says here).
And finally, I opened cmd, navigated to the library directory and run the command qmake -spec win32-g++ dxflib.pro (as suggested here). This created the make file.
Now run the command MinGW32-make. This will create a "release" folder with with a static library (that will be needed a the next step) and come .o files.
For question 2:
I used the Dev-C++ IDE. After I had created a project, I went to "project>project options".
Under "Directories>Include Directories" I added the path of the source code of the library (path_of_where_you_unziped_the_library\dxflib-3.7.5-src\src).
Also, under "Parameters>Linker" I added the .a file that is under the "release" folder (path_of_where_you_unziped_the_library\dxflib-3.7.5-src\release)
This worked for me :)
Just recently I installed Ubuntu and with it: Eclipse Version: Luna Service Release 2 (4.4.2) Build id: 20150219-0600. I've installed the MinGW GCC compiler via the command line option Ubuntu provides for my 64-bit system.
sudo apt-get install mingw-w64
When I made my project, Eclipse started to whine. It kept saying Toolchain "MinGW GCC" is not detected. It, however, does still find errors in my code. No errors are produced about it not being able to find the path of g++ or gcc, though. So I was searching Google and many sources said I would need to set the PATH variable of my installation. However I cannot find the installation path of MinGW-w64. How can I find what this path should be in Ubuntu 14.04 and set the path variable that needs to be set.
Additioanl information:
-At the end of this path Window->Preferences->C/C++->Build->Settings->Discovery->CDT GCC Built-in Compiler Settings has the command to get compiler specs as ${COMMAND} ${FLAGS} -E -P -v -dD "${INPUTS}"
-At the end of this path Window->Preferences->C/C++->Build->Environment has no Environment variables set at all, including the PATH variable.
-Under the following Project Properties->C/C++ Build both check marks are chosen.
->Build Variables is empty.
->Environment has the value of MINGW_HOME as /usr. The value of MSYS_HOME is blank. The value of PATH is ${MINGW_HOME}/bin:${MSYS_HOME}/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games.
->Tool Chain Editor has the check mark set to display compatible toolchains only, yet it seems to not have any effect on the which toolchain I can select in the following drop down menu. My current toolchain is set to MinGW GCC and my current builder is set to Gnu Make Builder
So again, my question is what gives? Why can't eclipse see the complier that I installed to my copy of Ubuntu? And how can I not only set my PATH variable, but I also must need to know what to set it to because I don't know where the terminal installed the /bin directory of mingw-w64?
First you need to understand mingw is a win32 port of the original GNU compiler. So, if you're already in Linux, you preferably will use this latter.
Now, you need to figure out if your system's shell recognizes it, so try tab autocompletion in the shell, wether its mingw or gcc, open up a terminal and type min and then hit Tab.
In case Tab autocompletion worked and you want to know where the command is located, you can use whereis [comand] and shell will return the path from where its running.
If nothing happens, then it's not in your PATH.
PATH is defined primarily in three configuration files: local PATH is in ~/.bashrc and ~/.bash_profile, and system PATH is defined in /etc/environment and /etc/profile but normally you wouldn't need to mess up with there two.
To find or locate anything in your system you can use find.
Normally, in every linux system, all binaries you install end up in /usr/bin,
/bin,
/usr/local/bin
or sometimes in /opt but that one is reserved in case its a third party vendor.
At this point you can do a search like find /usr/bin -name mingw taking the first argument as the path to search within OR you could search directly into your environment variables with env.
If you need to add something to the path I recommend you to create a symbolic link of your binary(no matter where its located) in /usr/bin and then, add that link to your local PATH, that is to say, something like this:
ln -S /opt/file.bin /usr/bin/myBin
echo "export PATH=$PATH:/usr/bin/myBin" >> ~/.profile
Normally after installing gcc eclipse should automatically detect it, but if not, you can set MINGW_HOME with the same code as above, just omit the symbolic link step and set the variable first as follows:
MINGW_HOME=/Path/found/of/mingw/or/gcc
I hope this explanation will help you, if not, feel free to share your thoughts.
I'm using Eclipse-CDT to develop and compile projects for Linux. As host both Linux or Windows may be used.
The project is created as Makefile project with a special build command, so I changed the build-command from make to our special one and the "Build" and "Clean" commandline approbriately. The build command uses a gcc from a directory not in $PATH, because the whole compiler-suite is located in the version control system. (Correct $PATH is set by the build command.)
This works fine under Linux: Eclipse learns the Symbols and Include Files automatically.
However, under Windows the Symbols are recognized, but the Include Paths aren't.
When I have a look in the generated MyProject.sc file in the workspace/.metadata/.plugins/org.eclipse.cdt.make.core directory, I see that the Include-Files are recognized, but prepended with a C:\cygwin.
The GCC command line uses absolute paths without the Drive letter.
(The whole source tree is located on a special Drive (e.g. W:), CWD is on this drive ).
E.g. gcc/g++ is invoked with -I /net_libs/lib1/inc and Eclipse recognizes C:\cygwin\net_libs\lib1\inc.
BTW: The standard-include paths are recognized correctly (e.g. W:/toolchain/win32/i686-pc-linux-gnu/include/c++/4.2.1).
The Build-Directory is set to the directory of the Makefile which is on the same Drive as the Sources and Includes.
I tried various "Toolchain" settings (Cygwin, MinGw, Linux gcc), the result is same every time. (After changing the settings, I even stopped Eclipse, deleted the sc file and started Eclipse again).
I don't know why Eclipse knows about my Cygwin installation in C:\Cygwin - the installation is NOT used by the compiler or related tools.
When I change the .sc file manually and correct the paths and restart Eclipse, everything works fine.
Do you have any hints what may be the problem?
Have a look at Project->Propterties->C/C++ Build->Discovery Options.
There is a Compiler invocation command - usually set to gcc, which means "gcc in PATH". Try setting this to your gcc from your build system.