Compiling error libgcc_s_dw2-1.dll missing nothing works - c++

I've found exactly the same topics on stackoverflow, unfortunately none of the solutions presented in similar topics actually worked in my case.
I'm using latest version of CodeLite 7 + MinGW, the problem I got is that everytime I want to compile c++ project I get the following message:
The program can't start because libgcc_s_dw2-1.dll is missing.
Problem known, but frankly nothing works in my case:
1) I did try to swap this file from CodeBlocks \bin directory - didn't work.
2) I did try to update MinGW libraries - didn't work.
3) I did try to add -static in linker options in CodeLite - didn't work
4) Set environmental path to C:\MinGW\bin - didn't work either
5) Download libgcc_s_dw2-1.dll from the Internet, swapped it - didn't work.
Maybe I'm missing something but I don't know how to handle it on my own.
Perhaps I might be doing something wrong with codelite build setting, can you please help me out with this ?

Go to C:/mingw/bin copy all dll files(it would be easy if u sort by type) and paste it in the codelite folder and you are done.

add the following in the project setting linker option:
-static-libgcc -static-libstdc++

Related

Missing dll's when compiling c++ programs using mingw compiler in cygwin

When I compile my c++ programs in cygwin with the mingw compiler, the resulting executables don't run because they're missing the following dll's:
libstdc++-6.dll
libgcc_s_seh-1.dll
libwinpthread-1.dll
An example of a compilation command:
$ x86_64-w64-mingw32-g++ -Wall deque.cc -o deque
I've tried adding the following linker options as well:
-static -static-libgcc -static-libstdc++
But they don't seem to be helping either.
I went looking through my dll's at:
C:\cygwin\lib\gcc\x86_64-w64-mingw32\5.4.0
But couldn't find the dll's there. Is it possible I just don't have these dll's on my computer? If so, where would I get them?
I understand there are other similar questions on stackoverflow, but looking through them I couldn't find any solid answers to this variation of the question.
Use https://cygwin.com/packages/ to search the contents of cygwin packages.
As reported by
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fmingw64-x86_64-gcc-g%2B%2B%2Fmingw64-x86_64-gcc-g%2B%2B-5.4.0-3&grep=libstdc%2B%2B-6.dll
usr/x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
same for
usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_seh-1.dll
usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll
I´ve had the same problem when compiling.
I decided to make a new instalation of cygwin, I followed instructions for a fresh instalation of cygwin from:
https://gist.github.com/patrickmoffitt/30684ec23fe82eabe0e3609cab2425b2
(in the point 6) using the package manager, selected the packages to install.... but in my case I also needed to install:
make
gdb
https://www.jetbrains.com/help/clion/quick-tutorial-on-configuring-clion-on-windows.html#Cygwin
At this point, when finish my new instalation, i added in the enviroment variables this route:
C:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\bin
(this route is where the .dll are)
This worked for me, hope this could help.
Another solution is, copying all the required .dll (form the path I mentioned) and pasting them where the .exe is. Do this every time is a bit annoying.

Cannot find -lSDLmain and -lSDL when compiling simple SDL program with g++

I installed SDL2 for mingw using this guide. However, when i try to compile using the compilation syntax and test code they provide, only with my own file names, I get the error shown here. I assume that this error has something to do with a problem in the way I installed SDL, as the installation instructions did not exactly match the files with which I was provided, but I did my best to follow them. Could they problem be something else? If not what is the correct way to install SDL2 for mingw?
Note: I do have the SDL2.dll file in the sdltest folder where I try to compile the program.
One way to let MinGW know where your SDL libraries are would be to create environment variable named "LIBRARY_PATH" with the value as the path to the directory containing the libraries. Similarly, you can have "CPLUS_INCLUDE_PATH" for the headers as well.
Did you follow step 2 of that tutorial ?

Why am I getting a procedure entry point error for this simple C++ code?

I'm writing an SFML game and when I try to run the code this is the error I get:
The procedure entry point _gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll
I've linked to all the libraries correctly and the include files are correct. I've even tried what other answers suggested by putting the libstdc++-6.dll inside the directory of my exectable but still nothing.
Another answer said to put the MinGW/bin directory before any other directory in the PATH environment variable, which I did as well and it still didn't work.
Note: I get this error only when I try to use SFML code. It runs successfully when I comment it out.
OK, the note you added tells me that the SFML stuff was compiled with another compiler version/configuration, newer one if memory serves right.
You need to make sure that SFML and your code are compiled by the same compiler (versions/configuration) or at least compatible compiler (versions/configuration).
I see that the latest binary packages of SFML use GCC 4.7, and the latest Code::Blocks (mingw) comes with the TDM GCC 4.7 build, so it might be enough to upgrade Code::Blocks and make sure you use the SFML GCC 4.7 TDM (SJLJ) package (and use the gcc that comes with Code::Blocks, of course).
Otherwise, you should probably install the TDM-GCC 4.7 compiler build manually, or if nothing works, compile SFML yourself.
This is just a PATH ordering issue.
Most likely you'll have multiple libstdc++-6.dll files loaded in your path. You can check by running where libstdc++-6.dll in your command prompt.
What you do is to make sure your MinGW bin folder is loaded before everything else. Try moving it to the first one in your global PATH.

SDL.h not found on g++ compile

Using OSX and vim...
Downloaded SDL2 from the website, then moved the SDL2.framework into /Library/Frameworks/
Using tutorial code, and Makefile... SDL.h is not found.
Makefile: g++sdl-config --cflags --libssdltest.cpp -o sdltest
I've read numerous things about pointing the compiler to the framework, but everything I've tried doesn't seem to work, and I thought /Library/Frameworks/ was the default area for the compiler to look
Got it to work.
Getting this to work took multiple tries, but the root of the issue for each try was that most of the Tutorials I was looking at were for SDL1.2 when I was using SDL2.
This changed flags in the make file, directories to search in and other things. Interestingly, I could never get the compiler to see SDL.h when it was in the /Library/Frameworks/ directory. However using Macports to install SDL2 allowed me to point the compiler to where Macports installed SDL2 header files - /opt/local/include/SDL2
That seems to have done it for me
Thank you for your question, because I was having similar difficulties! There seems to be a dearth of detailed and helpful tutorials on how to install SDL2 using Macports.
I got it working! Here are the steps:
Visit this link to find the Macports package appropriate for your version of Mac OS X. Install the version you need, and once that is done, proceed to step 2.
https://www.macports.org/install.php
After installation is done, visit this link to find the SDL2 port.
https://www.macports.org/ports.php?by=name&substr=libsdl
The one I needed was the third from the top, called libsdl2. I will be providing the name for you so feel free to visit the link simply for your own edification.
Open the Terminal, and type sudo port install libsdl2. If all goes to plan, you should see it installing and updating. Once it is complete, you should have a functional installation of the SDL2 Header files, (ending in .h), Static Library files (ending in .a) and Dynamic Library files (which contain dylib). You may have to do some poking around in Finder to locate where it installed.
The advantage of this workaround is the ability to use SDL with other IDE's besides Xcode, Eclipse for instance. Whereas Xcode requires you to assign a path of /Library/Frameworks, this technique should allow you to use the IDE of your choosing.
The final step is going into your IDE and assigning the build paths to these newly installed and compiled SDL files. For instance, the paths for mine are /opt/local/include and /opt/local/lib. Be mindful of the fact that your path may differ from these, but these examples should give you an idea of where to look.
Hopefully this is helpful for somebody!

NetBeans with C++ and OpenGL / Freeglut under Windows 7

I recently tried to figure out how to use freeglut with NetBeans 7.
I Google'd a lot and I didn't find a suitable tutorial on how to bind the stuff I need into it.
Currently I have more problem then this:
First one is:
- freeglut 2.8 => in order to compile it I need MinGW and msys.
I have both installed but I can't "configure" or "make all" and "make install" freeglut.
I didn't find an easy-to-read how-to for that task.
Next one:
- once built, where to put what files into a specific folder?
Last one:
- Once put the files into corresponding folder, how to use finally freeglut under NetBeans 7 on a C++ project?
I feel like a lack of information on that.
All I found are always answers like:
download, build, install and done. But I'm already stuck on the "install" and "build".
The solution:
Close NetBeans.
Install and download MinGW from mingw.org
After installing, add the Path to your SystemEnvironemt (example: C:\MinGW).
go to Start->Computer, right mousebutton, select properties
go to advanced system setting, in the following dialog press "Environment Variables".
in the tab "system variables", find the entry Path (or PATH)
add: C:\MinGW;
get freeglut pre-compiled package:
(http://www.transmissionzero.co.uk/computing/using-glut-with-mingw/)
there is a good tutorial how to set up.
Now have fun (just #include " and you're done.
have fun.
Note #1:
if you have problems finding make, the folder is:
C:\MinGW\msys\1.0\bin\make.exe
(when installed MinGW on C:\MinGW).
"mingw-get install msys" in command line should get msys...
last but not least dont forget to add msys\bin to path, too. :)
here's a full tutorial, but in german language.
http://techchan.blog.de/2012/03/18/einrichten-opengl-netbeans-7-1-1-teil-0-start-13209096/
If you need it in english, let me know if you could translate it ;) otherwise i'll think about to translate it myself.
I had a difficult time getting glut working in Netbeans on Windows 7 until I found freeglut, I attributed this to the fact that glut is just very out of date and so are the tutorials I found.
Maybe this will help others looking for instructions on using freeglut in Netbeans. These instructions are like the ones in the link already provided, but help explain how to use it in Netbeans rather than from the command line. This tutorial expects that you've already gotten Netbeans and your compiler working together. IF you have not done so, I found the guide here very helpful: http://netbeans.org/community/releases/68/cpp-setup-instructions.html#mingw
download and extract freeglut from http://www.transmissionzero.co.uk/computing/using-glut-with-mingw/ into an easy to reach folder. (I recommend C:/FrGlut)
either add the bin folder (C:\FrGlut\bin) to your Windows PATH variable, or copy the freeglut.dll from your bin folder into C:\Windows\System32
Open Netbeans and open or create your project
go to: file->project properties
Select your compiler, go to include directories, and add the path to your freeglut include folder (C:\FrGlut\include)
under linker, select add libary, and navigate to the file C:\FrGlut\lib\libfreeglut.a
select options and add the following individually:
-dynamic -lfreeglut -lopengl32 -LC:\FrGlut\lib\libfreeglut.a
Netbeans should now be ready to use with your freeglut library.
To use the glut libary add the following include to your source:
#include <GL/glut.h>
Remember that freeglut.dll will need to be shared along with your executable in order for the program to run, as most users will not already have it.