Program can't find libgcc_s_dw2-1.dll [duplicate] - c++

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

Cross Compiling from Linux-Windows, stdio has undefined references (to __imp___acrt_iob_func)

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.

problems with running c++-programs

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.

In CodeBlocks with compiler GCC, libgcc_s_sjlj_1.dll is missing

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.

C++ Deployment - dll files [duplicate]

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.

Specify location of g++ dependencies when compiling

So I'm using Anaconda to run Python 2.7 32-bit on my company's server. That works dandy. Anaconda came with MinGW, so I'm attempting to use the g++ compiler in there. Everything works for me. I can compile c++ source, and then run the resulting executable. The issue comes when coworkers try to do the same. Apparently, the g++ compiler creates a dependency for the executable it makes on a particular dll located within Anaconda. I have a path variable to where this dll lives, my coworkers do not, thus, they cannot run any executable made by g++.
Is there a way to specify where this dll dependency is when I compile executable so that anyone can use them? Something like:
g++ someCode.cpp -o someCode.exe locationOfDll=path2dll
Just to be clear, everyone can successfully compile c++ source code, but only I can run the resulting executable. Thanks in advance
EDIT: I forgot to mention that simply giving everyone the path variable is not an option.
Does this help? It discusses updating the library search paths.
http://www.mingw.org/wiki/HOWTO_Specify_the_Location_of_Libraries_for_use_with_MinGW