I've done some googling and everything already but none of the solutions online exactly match my situation. So I have one project which has the files
Main.cpp
BankAccount.hpp
BanckAccount.cpp
GoCardAccount.hpp
GoCardAccount.cpp
And when I compile it, it is completely fine. But running it gives me the following image:
The things I have tried:
Reinstalling MinGW
Putting the libstdc++6.dll in System32
(The only thing that works) putting the libstdc++6.dll in the project directory.
I feel like this is not the best option. Especially since if I write a small "Hello World" program, then the error does not appear.
Is there any way of actually fixing this?
Related
I'm following the gtkmm tutorial for gtkmm4 and I'm getting an odd error when I try to run my program. The program is an exact copy of the provided code, and it compiles successfully:
However, when I run the program it gives me a series of errors:
I'm not sure what to do at this point. I've tried googling, but I don't get anything helpful. I've check that the DLL in question does exist. Any advice is appreciated!
Edit: I ran the Dependency Walker program, and got some errors, not sure what this means though.
Edit2: I did some research on Dependency Walker, and it seems to have some known issues, so I also ran lucasg's "Dependencys" program, with this output. I'm still not really sure what this means, but it seems fine.
Edit3: I moved the 4 offending dll files into the build directory, and these are the new errors I'm getting. Its the same error, but now it points to the more local file.
Check your .exe file with Dependency Walker to see which issues there are loading the .dll files.
One possible cause could be that you're mixing 32-bit and 64-bit.
The issue was something to do with finding the correct DLLs. The solution, as outlined here, is to copy all the DLLs from C:\msys64\mingw64\bin into the build directory. Then, using ntldd or some other profiler, determine which DLLs are unnecessary and remove them.
So I have this issue and I cannot seem to find a solution to it online. I am dynamically linking SFML following this tutorial using the same exact versions of both Codeblocks and SFML. It works perfectly fine in the IDE but when I try to run the EXE file from the release folder (Yes, I do have all my SFML DLLs in the same folder) it gives 3 errors along the lines of:
_ZSt4_throw_out_of_range_fmtPKcz could not be located in sfml-graphics-2.dll
I also tried linking it statically according to this guide, however this is worse since it doesn't even compile. It gives errors along the lines of:
undefined reference to 'FT_Set_Pixel_Sizes'
Honestly I am lost and out of ideas at this point. Any ideas on what I could be doing wrong?
I have downloaded gorilla-audio source code to use it in my software, but when I use the external library from OpenAL (in gorilla-audio, the OpenAL32.lib) the project compiles with no errors or anything, but it doesn't run normally, I still haven't implemented anything from gorilla sound, just wanted to check that after adding the library it would still work the same before editing anything, but it just doesn't, I have linked everything and used the correct version of .lib but when I run the project it says:
The program can't start because OpenAL32.dll is missing from your
computer. Try reinstalling the program to fix this problem.
What should I do, I've googled that but I'm just scared to download random things, plus I don't even know where should I put it.
Any help guys,
Thanks ^_^
I'm doing a tutorial on SDL, and I'm having some issues
I just did this where I do the basic stuff to get SDL to run. I then ran the test code (which is on that page) and it worked. However, now I'm trying to run the code here, and it's giving me this list of errors.
What could be the problem? There was one weird thing, I don't know if it's relevant, to get the first code running I had to put SDL2.dll in the SysWOW64 folder even though both my compiler and version of the library are 32-bit. Again, I haven't a clue whether that could mean anything, especially because I got the first thing to run perfectly.
Edit: Also, Code::Blocks shows me the error in SDL_platform.h, a file completely identical to my 01_hello_SDL.cpp. I'm a complete noob to SDL and even though I have done some pure C++ I haven't used it with an external library before, so I have no idea what that means.
Edit: Here's my setup:
I copied the contents of the 32 bit folder to C:\mingw_dev_lib\sdl, resulting in C:\mingw_dev_lib\sdl\bin, C:\mingw_dev_lib\sdl\include, C:\mingw_dev_lib\sdl\lib and C:\mingw_dev_lib\sdl\share.
I copied SDL2.dll to both C:\Windows\System32 and C:\Windows\SysWOW64.
In Code::Blocks my setup is like this: In build options, in the linker settings tab I put -lmingw32 -lSDL2main -lSDL2. In the search directories tab, in the Compiler subtab I have C:\mingw_dev_lib\sdl\include\SDL2 and in the Linker subtab I have C:\mingw_dev_lib\sdl\lib.
This got the test (which you can find at bottom of the page of first link) to work. However, the second program (at the bottom of the page of second link) gives me the errors in the third link.
First of all you need to put SDL2.dll in the SysWOW64 folder because you're linking SDL2 dynamically and when you execute the program it needs to find the SDL2.dll file in basically two folders:
The folder where the program resides.
System32 (or his 64 bit counterpart SysWOW64).
Therefore i can't give you an accurate answer based on the compilation errors you get, please show how you're including SDL2 and the Code::Blocks configuration.
I've recently started using PDCurses in a C++ game I'm working on. When I compile the program on my own machine (windows) and run the .exe, everything works as it should.
When I take that .exe onto a different computer that doesn't have PDCurses and I try to run it, I get an error about a missing pdcurses.dll file.
After doing a bit of research online, I found out that including the .dll file along with the .exe should make it run but it didn't work for me.
This is how I compiled the program using MinGW: g++ game.cpp -o game -lpdcurses
So my question is, how do I make this program run on computers that don't have PDCurses setup, and also, is there a way to do this by combining the .exe with whatever additional file(s) the system needs to run the program? I've also read that you can do some sort of static linking but so far I've been unable to find a way to do this.
Thanks in advance for the help.
NOTE: In case it matters, I setup PDCurses following this tutorial: http://comptb.cects.com/1848-adding-pdcurses-to-mingw
Not sure if that was the best way to do it but I'm able to compile and run C++ code that uses pdcurses on my computer fine.
Sorry for not posting the exact messages. Here they are:
The first one I got when I didn't include the pdcurses.dll file along with the executable said :
The program can't start because pdcurses.dll is missing from your computer. Try reinstalling the program to fix this problem.
The second one I got after I included the pdcurses.dll:
*The program can't start because libcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem.*
You need to include all the dynamic libraries you linked with. Be careful of licensing, although IIRC there's not much that will bite you with MinGW.
There should be a 'ldd' command if you have the MinGW shell. Try running it on game.exe and it will tell you what libraries you need to run your program. You need to include them all with the exe.
If you want to try and remove the dependency nightmare you can use the static linking (-static) option to your gcc link command. You may not be able to actually do that if you don't have the static versions of your libraries installed. This has other implications - your exe will be bigger and the OS's shared shared page code will not work because it can't tell what parts (DLL code) you are sharing with other apps. In effect, your application will use more memory as a result, although it may be insignificant.
Another option is to get the sources to PDCurses and compile it as a static library. That way you don't have to get involved in the DLL Hell.
Compile it as a C library instead of a C++ library and you should be good to go.