I started programming in C++ using CLion IDE.
When I run the program inside the IDE it works. However, opening the .exe file outside the IDE generates a bunch of errors:
The code execution cannot proceed because libgcc_s_seh-1.dll was not found. Reinstalling the program may fix this problem.
Hitting OK pops the same message again with a different dll.
Why does this happen? What are the different ways to fix it? What is the best option?
You always need to ship any libraries your application is linked with along with your application. The libraries are just as much a part of your app as the code you wrote yourself. This includes your compilers runtime libraries (which you forgot in this case).
Related
I'm using QtCreator with the visual studio 2015 kit on windows 8.1 to build a program I developed and tested on Linux, on linux it works correctly, but on windows it's just crashing immediately, and I have no idea what to look for.
The only external libraries, aside from QT I'm using are opengl and glew, so I don't think it's those.
Is there anything that's known to work in GNU C++ but crash immediately in MSVC?
Usually this kind of crashes have absolutely nothing to do with your program. It's an external library linking issue. I had this issue recently with the OpenSplice DDS library. I linked to a library that caused a segmentation fault before anything started. I resolved the issue by linking the pre-compiled libraries 1-by-1, and check each if that fixes the program.
What I recommend you to do is: Remove the libraries and resources you're linking to gradually, until your program starts and prints "Hello world" from the first line of main().
Another way to go is, make a new empty program, and link the same resources you're using in your program. This is easier, as it doesn't involve modifying your program.
This is what I would do.
Start by rebuilding the entire solution or project from a clean state. Just in case this is just some weird dependency issue that resulted in something not getting recompiled. Never hurts.
As Neil said in the comments for the question, the crash is possibly coming from a global variable who's constructor runs before main or WinMain. Are you sure you don't have something declared as "static" or at global scope that might have a constructor?
Now do the following:
Open Visual Studio.
From the menu, select File->Open->Project/Solution...
When the file open dialog pops up, select the EXE produced by Qt
Creator. (That's right - you are opening the EXE as a project). This directory is typically one folder level above the Qt project (..\build-yourapp-Desktop_Qt_5_7_0_MSVC2015_32bit-Debug\debug)
Now press the green arrow to start debugging (menu->Debug->Start
Debugging). If all goes well, your program will fail early and
Now chances are high that the program is not going to run at all under Visual Studio because Qt Creator doesn't copy all the Qt*.dll binaries to your build directory. You'll get a bunch of dialogs popping up saying that "The program can't start because Qt5-XYZ.dll can't be found". This is easily fixed by updating your PATH environment in any of the following way to include your Qt5.x.0\5.x\msvc2015\bin folder to your PATH.
You add it from the command linke and then re-launch devenv.exe from the command line.
You can add it globally from Control Panel->System->Advanced. Then restart Visual Studio from the Windows desktop.
With the EXE debug project open from within Visual Studio, just right click on the project name (not parent solution) and a dialog will popup that allows you to edit startup settings. One of which is the Environment.
And that should do it. From there you can start the debugger on your EXE, set breakpoints as needed, and analyze the call stack on crash.
It's really easy: build all the libraries you use, including Qt, with debug information (those can be release builds as long as the PDB files are generated). Then run your application under a debugger (e.g. F5 under Qt Creator), and it will stop at the point of the crash.
The code that runs before main and is known to cause trouble will be the global object initialization: you're likely running into the static initialization order fiasco.
Another cause for the problem could be stackoverflow. In Linux, the stack size by default is usually 8 MB whereas in Windows it's just 1 MB.
Try to link with /STACK:8388608 switch. If it works, you might consider allocating more data on the heap and stay with the default stack size of 1 MB.
I have, after some effort, successfully built a little piece of example code and make it run. I am using C++ in CodeBlocks 13.12 on a Win 7 x64 machine. The program makes use of wxWidgets and OpenGL libraries.
The problem is, that in order to make the EXE run successfully, I had to copy these DLL files to the location of EXE :
wxbase30ud_gcc481TDM.dll
wxmsw30u_core_gcc481TDM.dll
wxmsw30u_gcc48.dll
wxmsw30ud_core_gcc481TDM.dll
wxmsw30ud_gl_gcc481TDM.dll
I would like to know how to build the program ( what settings to change in project) so that the EXE file will be able to run on its own ( and also on other machines ) - without "missing DLL" error messages ? It would be nice if answer could be general and useful as a reference in future, similar issues.
In the linker, you could add lines similar to this one:
-static wxbase30ud_gcc481TDM
However, this isn't terribly effective or good practice. Better would be to go ahead and include the dll's with your .exe, and simply supply a shortcut to your program that the user could move anywhere. This allows you to install and keep all your program files together, but still let the user only worry about one for the entire thing.
You could use something like Enigma Box, which packs the DLLs into an exe and if you call LoadLibrary it will function as expected:
http://enigmaprotector.com/en/about.html
Some others exist like ILMerge or XBundler I heard as well... haven't used them though. I heard DLLPack too.
I'm getting ready to enter Ludum Dare this evening, and I'm getting really frustrated because I'm unable to build my project into a standalone .exe.
I feel like this question has been asked at least 100 times but none of the answers I'm finding are helping me out at all... I don't really understand what static linking is or how to do it, and that doesn't even seem like the solution to my problem; I don't mind if I'm shipping out a bunch of .dll files with my program, I just want the program to run on its own so I can submit it at the end of the competition.
Basically, my visual studio (2010 express) configuration follows exactly LazyFoo's tutorial on setting it up. Everything runs fine on both debug and release configurations when I start the program from visual studio, but when I navigate into the Debug or Release folders of the project and try to run the .exe, the programs break with an error about abort() being called, or they give me the error "X program has stopped working."
I'm including all of my DLLs in the same folder as the executables are being placed, and the game runs perfectly fine from inside VS, but I just can't seem how to figure out how to compile it as a standalone .exe (or even including a folder full of dlls) without it falling apart.
Can someone give me a pretty precise way to get this working? Any help would be great.
If you have an EXE, then your program is compiling. Most likely in debug mode, the program is running using a specific directory as the current working directory (CWD), but when you run it as standalone, the CWD is different.
The CWD affects both the DLL that can be loaded as well as the search of any file that uses a relative path (that is, not starting with a [back]slash). That is probably your problem: textures, graphics, configuration files, fonts...
My advise is to set the CWD in the debugging runs (there is an option for that) to be exactly the same than that of the EXE, that is the default when you run the EXE. Then you will be able to debug your crash.
I was writing a simple pong application and while its not finished I'd lie to be able to figure out how to compile it for release. I get no errors and i linked against SDL, SDLmain,SDL_image,SDL_ttf but when people on other computers try to run it (both the debug and release) it closes as if it's missing files. I put SDL.dll,SDL_image.dll, SDL-ttf.dll all in there along with the images i use in the program, it works fine on my computer so that says theres a file I'm missing for it...but what would that be?
EDIT:
Finally after 30 minutes i figured it out: when including SDL_image.dll you also have to include SDL_image.dll's dependencies : zlib1.dll,libjjpeg-x.dll,libpng..etc
A good way to solve this sort of problem (if it's DLL related) is to use Dependency Walker. This will show you all the dependencies of an executable, and the dependencies of the dependencies.
If you run it on the target platform, it will highlight DLLs that are required but not available, making it easier to see why your executable won't run.
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.