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.
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'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.
I have C program I compile with mingw on Windows. It works fine but requires MSVCRT.DLL. I want to link that statically (like I can do in Visual Studio). Is this possible?
I tried -static flag to gcc and it didn't make any change.
What about C++ program using also standard C++ library?
I believe that MinGW doesn't use the static runtime library for copyright reasons.
You can maybe try to use newlib (http://sourceware.org/newlib/) to create an executable that doesn't link to msvcrt.dll
Having spent a while searching for this myself, I came across this post introducing the in-progress Mingw32 Alternate C Runtime Library. However, it's not ready for use, and the developer appears to have abandoned it. Home page link here.
Posting this answer here in the hope that it'll come in useful to people googling at some point in future.
This doesn't answer the question of "how to avoid linking with MSVCRT.DLL", but if you're here for a more general question of "How to link with MinGW statically"...:
Link with gcc -static -static-libgcc -static-libstdc++ and you won't need libgcc_s_dw2-1.dll and libstdc++-6.dll
I know how to use g++ and all that to compile c++ programs.
My question is, if I have some code which depends on various libraries, how can I compile it into a simple executable that I can send anyone. For this I would be happy with just keeping it on os x.
I would like to know how to compile a "real" program not just an executable I can run locally.
I have tried googling this but haven't found much.
Do I have to use installing software?
I know in windows you can make some simple .exe stuff that use common DLL files.
You a looking for "static linking". That will import all the needed code from the libraries into your executable. Note the executable will get larger. If you are using standard libraries, they should be present on standard OS installation.
You should try "-static" flag of g++.
Running "ldd your_executable_name" should display all libraries your executable uses (linked dynamically).
Since you are talking about Mac OS X, you probably want to make a bundle. Qt Software has a very useful deployment guide for getting started with this kind of activity.
You can use -static or -s option for static linking in gcc or g++
Where can I find an writeup that shows me how to set up a tool chain for WxWidgets (C++) on linux/ubunto and/or OS X.
I downloaded, compiled & installed WxWidgets both on linux and OS X, compiled and tried the samples, but seem to be stuck setting up a compile environment in my own home directory.
DialogBlocks from http://www.dialogblocks.com looked promising, but it insists on recompiling WxWidgets again and again .. must be something about it I don't understand.
Writing code from scratch seems to fail due to a lack of paths to libraries, tools or whatnot .. again a lack og understanding on my part, I am sure.
So, can anyone point me to a tool chain setup, that has more than the bare minimum of instructions and fills in some of the "why" instead of only the minimal "what".
Like all C/C++ programs, the compiler has to know in what directories to look for include files, and the linker has to know what libraries it should link to.
The WxWidgets package, if installed correctly, includes the program wx-config. This can be used while compiling and linking, like so:
g++ $(wx-config --cxxflags) -c my_prog.cpp
g++ my_prog.o $(wx-config --libs) -o my_prog
I've found these two pages to be of help when setting up wxWidgets for Eclipse and MinGW.