This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
The program can't start because libgcc_s_dw2-1.dll is missing
I'm using Code::Blocks and MinGW 4.4 (I think) compiler to create a C++ project. I get this system error if I run it from its directory, but not from within Code::Blocks.
The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
In this post hardmath said to add -static-libgcc to the compiler flags, linking to the dll statically. When I tried this the error still occurred. I could get it to work by adding the MinGW bin directory to my computer's Path variable, but I plan on distributing my program across the internet.
The issue only appeared after updating to the latest G++ compiler. What's the reason for this solution working for everyone else apart from me?
The link commandline argument -static-libgcc should work. Another variant you could try is plain -static.
If you don't want to worry about this, and still want to redistribute your binary, just copy the relevant dll from MinGW's bin directory and place it alongside your executable. This is common practice and works as advertised.
Related
As the title says, I've been trying to cross compile a fairly large project with quite a few dependencies (both static and dynamic libraries). I've cross compiled every dependency successfully using MinGW-w64, set the include & library search paths to their MinGW counterparts (/usr/x86_64-w64-mingw32/lib & include), and yet on the linking step MinGW throws out an error for each call of printf (with stdio.h included, of course). The errors are as follows:
/usr/bin/x86_64-w64-mingw32-ld: ./obj/XXXX.o:/usr/share/mingw-w64/include/stdio.h:352: undefined reference to `__imp___acrt_iob_func'
(Where "XXXX" is a file name from my project)
This error is repeated the exact same (with the exception of the object file name). The command for linking looks like this:
/usr/bin/x86_64-w64-mingw32-g++ -o bin/ReleaseWin/Project #[file with object file names] -L. -L/usr/x86_64-w64-mingw32/lib/ [linking some dependencies (boost, openGL, SDL2, etc.)...] -m64 -flto
I've searched for a solution (or even someone with the same problem) to no avail. I've never been well-versed in linking any more than regular libraries, so if you need more information just ask.
Thanks in advance :)
Extra info:
This project has been cross compiled (from Linux to Windows) successfully before, and I haven't added/removed any dependencies since.
My MinGW-w64 version is 7.0.0
So, I apt-get purge'd mingw-w64 and mingw-w64-common, reinstalled just mingw-w64, and now it's working...
This might have something to do with the fact that I followed the issue that Richard Critten commented with (thanks!), which led me to try downloading and manually copy/pasting headers and CRT (mingw-w64-x86_64-headers-git-... & mingw-w64-x86_64-crt-git) from the MSYS2 repository. That didn't work right away (probably because I screwed up and used the 5.0.0 versions instead of my version), but it seems to have done something.
Therefore, for those who stumble upon this issue,
Try a re-install of MinGW (of course),
Try manually adding the CRT and headers from the link I supplied, and if that still doesn't work,
Try re-installing MinGW again. I'm not super familiar with apt, so I don't know if adding the CRT and headers actually changed how it installed MinGW, but it's worth a shot I guess.
Update: I had this exact same problem on another system. Simply reinstalling MinGW fixed it, so it seems like maybe there was some sort of issue with the files? It's possible that updating from an earlier version messed with things. Moral of the story: even if you think your files are good, a reinstall can't hurt.
I wrote a c++-program including <iostream> to use std::cout and std::cin. I compiled it with the g++ compiler (GNU compiler collection) on Windows 10 using MinGW. When I run the program with the run-terminal of MinGW it works but when I try to run it with cmd.exe or open it in Windows Explorer I get this Error:
"The program cannot be run because libstdc++-6.dll is missing. Please reinstall the program to solve the problem."
Because I didn´t install my program, I tried to install libstdc++-6.dll. I downloaded the file in zip-format but I don´t know where to unpack. Has this file to be in system32? Do I have another problem? Can anyone help me to solve it? I already read a simliar question and its answers but -static-libgcc -static-libstdc++ didn´t work.
This is a repetition of this question libstdc++-6.dll not found according to #kerrek-sb do this
If you are using MingW to compile C++ code on Windows, you may like to add the options -static-libgcc and -static-libstdc++ to link the C and C++ standard libraries statically and thus remove the need to carry around any separate copies of those. Version management of libraries is a pain in Windows, so I've found this approach the quickest and cleanest solution to creating Windows binaries.
You might want to compile your code with g++ and the options -static-libgcc and -static-libstdc++ so to link the C and C++ standard libraries statically. As a result you don't have to install libraries in your Windows path and you can carry around the executable on other systems.
I'm trying to run my first SFML program using Code::Blocks 16.01. It compiles, but then warns me that libgcc_s_sjlj-1.dll is missing. My compiler is GCC 4.8.1-4. Other similar questions, such as: "libgcc_s_sjlj-1.dll" is missing, have said to use linker flags, so I included -static-libgcc and -static-libstdc++as linker flags, but that didn't work.
The MinGW bin is included in my path. I have copied the .dlls into the directory with my executable. I looked in the actual bin and the .dll isn't even actually there, so I have reinstalled MinGW a couple times.
One thing I have not done is download the .dll itself which I have read is not a good idea. I'm not sure how to get past this error.
Yes, it's a problem about dynamic linking and static linking.
I met this confusion several months ago, when I build and run my little code snippet, the computer warned me that "stdc++-6.dll" was missing, so I tried to google and download the .dll file(which should be located in c:\windows\system32), but it didn't work, because when I run my program next, it warns that "libgcc_s_sjlj-1.dll is missing".
I didn't download the file, but I make some "extra settings" like you, I included -static-libgcc and -static-libstdc++ as linker flags, and it didn't work either, then I include -static.
Then my codes work so well. And I wish it could help you.
P.S.I have written an article in Chinese to talk about this problem.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
The program can't start because libgcc_s_dw2-1.dll is missing
I'm using Code::Blocks and MinGW 4.4 (I think) compiler to create a C++ project. I get this system error if I run it from its directory, but not from within Code::Blocks.
The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
In this post hardmath said to add -static-libgcc to the compiler flags, linking to the dll statically. When I tried this the error still occurred. I could get it to work by adding the MinGW bin directory to my computer's Path variable, but I plan on distributing my program across the internet.
The issue only appeared after updating to the latest G++ compiler. What's the reason for this solution working for everyone else apart from me?
The link commandline argument -static-libgcc should work. Another variant you could try is plain -static.
If you don't want to worry about this, and still want to redistribute your binary, just copy the relevant dll from MinGW's bin directory and place it alongside your executable. This is common practice and works as advertised.
I used CMake and Visual C++ to build the HyDE library. Then, still in VC++, I was able to successfully create code and build an executable that links into HyDE.lib and the HyDE header files.
I then discovered that in order to work with others at my company, it would be preferable to develop in Eclipse CDT. Knowing very little about Eclipse CDT, I created a default hello world project, deleted the code and then dumped in all of my code into the src folder. Then I attempted to change the includes and lib path and libs to mirror what had worked in VC++. At this point everything seems to compile, but I get an error in linking:
/cygdrive/c/EclipseWorkspace/425HyDE/Debug/../src/FS5HyDE.cpp:16: undefined reference to `HyDEAPI::HyDE::HyDE(HyDESystemModel::SystemModel*, bool)'
(There are many more errors like this, all referring to HyDE methods.) Here is what is being run at the command line:
g++ -L"C:\Progra~1\boost\boost_1_42\lib" -L"C:\EclipseWorkspace\HyDE" -o"425HyDE.exe" ./src/Adapter_FS5HyDE.o ./src/EPSCommands.o ./src/EPSCurrentSensor.o ./src/EPSFault.o ./src/FS5HyDE.o ./src/HyDEObservation.o ./src/MCDH.o ./src/MCDH_Module.o ./src/PDBComponent.o ./src/PowerSystem.o ./src/Program.o ./src/SSPCComponent.o ./src/Telemetry.o ./src/TelemetryReport.o -l:libboost_thread-vc90-mt-gd-1_42.lib -lHyDE
This is definitely not a library ordering problem because I've the other ordering as well (there are only two). Is it possible that there is a problem with compiling HyDE.lib in VC++ (which uses a Windows compiler) and compiling my program with g++? Could there be a problem in the way that Eclipse CDT is autogen'ing the makefiles? Any other ideas?
(Note: there appear to be plenty of others questions on SO with similar problems, but after reading through them I have yet to find one that addresses my problem.)
Classic missing symbol error. Which source file defines:
HyDEAPI::HyDE::HyDE(HyDESystemModel::SystemModel*, bool)' ?
Was this file added to the compilation? Can you spot it on the command line you pasted?
If this symbol belongs to an external library, after adding the directory path with -L , you could add the name of the specific library you want to link with your program using -l.
I'm going to suggest that you try to add to the compilation command the directory path to HyDE.lib, followed immediately by the library name, like this:
-L"C:\path_to_hyde_library" -l:HyDE.lib
and then tell us what happened.
Solution: Since the HyDE library was compiled with the Visual Studios compiler and I'm attempting to build the code that links to it with the Cygwin toolchain the two compilers use different name mangling schemes so that the latter linker can not find the expected symbols in the HyDE library. The only solution that I've found is to recompile the HyDE library with the Cygwin toolchain or compile the new code with whatever compiler Visual Studios is using. (grumble grumble)
./src/FS5HyDE.o and ./src/HyDEObservation.o should be the latest parameter if other object files (*.o files) need them, it means that the most needed object files should be appeared as last as possible in the parameters list.