I'm coding on CLion and made this log in function. The tests are being made through the .exe because CLion's Terminal sometimes jacks up the I/O's. The problem is my .exe is not finding the files I'm specifying. It runs properly through the CLion terminal, but when shifting to the .exe it doesn't.
I've read that putting those files in the cmake-build-debug/ directory fixes the issue - and it does. Thing is, this is a group project, and by putting those files in that directory I'll constantly run into compatibility troubles when pulling from git - .cmake-build-debug would have to be pushed, thus i'd have to reload it every time. This doesn't seem very proper to me.
The other option is to put the .exe file and required .dll's in the main directory. Again, would have to update this file every single time i build the project, which also isn't a very practical solution.
So I'm asking for some help regarding what can I do to ensure my .exe searches for files in the main directory, not just on the cmake-build-debug directory. The directories are included in CMakeLists, and the .exe still doesn't find them. This is quite the issue. The project will also include some rudimental form of database, so file handling will be important. Would be nice to be able to code and build without having to manually change stuff around every single time.
I am using the Atom text editor to write c/c++ codes. By default I need to save all my programs in the C:>.atom> packages> MinGW> bin folder.
Now, I want to change the location where my programs are stored to a new folder which is comfortably placed in say, C:> My Programs. This works fine in CodeBlocks and before creating any console application there, I can choose the location manually and therefore all my programs are neatly arranged in the folder C:> My Programs that I have created. But, when I try to place a program anywhere other than the C:>.atom> packages> MinGW> bin folder or simply try to open a previously created program (with CodeBlocks) from the C:> My Programs folder, this error pops up in Atom -
'g++' could not be spawned. Is it installed and on your path? If so please open an issue on the package spawning process.
I don't know what to do.. How can I 'tell' the gcc compiler that look into this file rather than the default?
Can anyone please guide me through the steps?
Thank you so much.
As stated in this post the working directory when I debug my SDL program is relative to the .vcproj instead of the .exe (which it should be IMO)
So I'm wondering if there's anyway I can change this, so when i press F5 the path will be relative to the .exe and not .vcproj?
The current (relatively easy) workaround I'm using, is simply opening up the folder and starting program from there, but I would much rather prefer simply pressing F5.
The naive answer to your question is that you can set the Working Directory option in the Debugging configuration properties to $(TargetDir). The default setting is $(ProjectDir) and by default the project directory is not where the executable file is output. However, I do not recommend you take this option, as I explain below.
You are attempting to solve this the wrong way. Your fundamental problem is that you are assuming that the working directory is the same as directory which contains the executable file. There's no reason for that to be so, and you should not rely one it. You know that the files are in the same directory as the executable and so you should look there, rather than the working directory which is only sometimes, coincidentally, the same as the executable directory.
So, instead of relying on the invoker of the process setting up the working directory to your liking, make your program independent of the working directory. You state that you wish to work with files whose location you know relative to the executable directory. So there is the answer. Construct full paths to your files, using the directory which contains the executable as the base.
If you need to find out the location of the executable, call GetModuleFileName(), and strip off the file name. What you have left is the directory which contains your executable. Combine that with the relative path of your files and your code is now independent from the working directory.
I recently installed MinGW on my 64-bit Windows 7 computer and when I attempt to compile the most basic of c++ programs, for example
#include<iostream>
using namespace std;
int main()
{
cout << "Hello World" << endl;
return 0;
}
I get the error that "The program can't start because libgmp-10.dll is missing from your computer."
Have you tried adding C:\MinGW\bin as a System variable Path (not PATH) in Settings->System Properties->Environment Variables?
I saw this solution on this page: Missing libgmp-10.dll
Go to the mingw download page and browse the following directories:
MinGW / Base / gmp / gmp-5.0.1-1
Currently you end up with the following link:
http://sourceforge.net/projects/mingw/files/MinGW/Base/gmp/gmp-5.0.1-1/libgmp-5.0.1-1-mingw32-dll-10.tar.lzma/download
and it contains the needed file.
I know there are automated methods for installing mingw gcc, but when one uses single mingw packages, then gmp is one of obligatory downloads.
added
c:/MinGW/bin to PATH
and restarted CMake-gui
worked for me
I came upon this question when I started CodeBlocks and then clicked on my project. After the project notes appeared and I pressed OK, the error appeared:
"System Error: The program can't start because libgmp-10.dll is missing from your computer.
Please reinstall the application to fix this problem."
I presse OK a bunch of times and then was able to do normal compile, link, etc. but that error showed up everytime I started C::B and went to the project. Then I noticed that the LLVM Clang compiler was my default compiler in the compiler settings, though GCC was set as the compiler specific to the project I was working on.
The solution was to set the compiler in the compiler settings to GCC (mingw) and also set it as the default compiler. After that this system error stopped popping up every time I started the project.
The reason I posted this answer is because it answers the OP's question and other people with the same question may have a similar reason for this irritation, and my personal experience in this matter may prove useful to those people.
If you did not find this file in your installation directory, and then went to the site [Click here] to download the file, and then extract it to your installation directory.enjoy:-)
Caution - removing stuff from your path can compromise your system!
Interestingly, you not only need to add the MinGW bin to your Path, but also you need to make sure that certain things are not on your path*. In my case, I saved my entire path variable as a backup, deleted everything non-system from my path except for MinGW and CMake, leaving:
C:\MinGW\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files (x86)\CMake\bin
You should use the appropriate elements from your system path.
I first tried to do this with a batch job that launched CMake, but it seems that the CMake GUI was reaching back and grabbing the System 'Path' variable instead of the command prompt 'Path' variable, which I had printed and confirmed was as listed above before launching CMake.
Incidentally, I backed up the entire Windows VM before starting!
* For instance: various references, including known issues, mention sh.exe. I inherited this VM from my client and hacked it up further, so it's easier for me to use a clean path for my cross-compiling task and return afterward...
In just installed MinGW using the mingw-get-setup.exe v0.6.2beta-20131004-1 installer. Even though during the install I selected the gcc package, the installer didn't include the "mingw32-gmp" package, which includes libgmp-10.dll. I had to rerun the installer, chose the "Reinstall" option, and manually select the "mingw32-gmp dev" package.
If you don't have the permission modifying your global path, you can also change the active directory of your cmd shell.
How to do it (in the cmd shell):
C:\> cd C:\MINGW\bin
C:\MINGW\bin> gpp.exe C:\Users\James\Desktop\Program.cpp
How it doesn't work:
C:\>C:\MINGW\bin\gpp.exe C:\Users\James\Desktop\Program.cpp
Note: you have to change "C:\Users\James\Desktop\Programm.cpp" to wherever your program lays
How it works: windows looks for needed DLLs while in the same directory and if it can't find it there it'll look in the PATH variables (so it will search system32 by default), if you add any missing DLLs to the directory from where you run it, windows looks and uses them (even before it looks in the PATH).
A very simple fix to this problem of having missing driver file/s is to select and copy all the dll files from C:\MinGW\Bin and paste them into your C:\MyPrograms or whereever else your folder for created c++ (.cpp) files are being located.
Just search google for the dll file and download it. Then paste it into the folder in this path
C:\MinGW\libexec\gcc\mingw32\9.2.0
I am writing code that opens an istream object on a file specified by the user. I want to be able to run the program in the debugger and just type the filename (eg data.txt) at the prompt, not the whole path. I haven't worked out how to do this inside the IDE so I have been saving my .txt file to the debug folder and running the .exe file, but that means I can't step through the program. How do I make it work inside the IDE instead? Thanks.
you can set the working path of the executable (project properties->Debugging->Working Directory), which leads the debugger to start the executable with that path as working directory. This has the advantage that if you set the same path for all your configurations (Debug/Release/...), you only need 1 data.txt on your entire system, which is especially nice if you want to change data.txt or it's name.
I am not sure I understand exactly the problem - is it that your data file is part of the project, but is not in the executable folder when you access it, or is it that the datafile is at another location? If the former, and the data file is part of the project, right-click on the file, and set the Build Action property to "Content". That way, it will get copied to the bin/debug folder where the executable runs when you debug.