SFML community forums
Help => General => Topic started by: dense on April 25, 2011, 11:09:28 pm
-
I get this error when i compile the code on the first tutorial.
This application failed to start because libgcc_s_dw2-1.dll was not found. Re-installing the application may fix this problem.
#include <SFML/System.hpp>
#include <iostream>
int main()
{
sf::Clock Clock;
while (Clock.GetElapsedTime() < 5.f)
{
std::cout << Clock.GetElapsedTime() << std::endl;
sf::Sleep(0.5f);
}
return 0;
}
I'm using Code::Blocks on WinXP. I also get this error on Visual Studio too.
tnx
-
This DLL is in mingw/bin, you must copy it in the same directory as your executable. Or compile with the "static-libgcc" linker flag to get rid of it.
-
I can't find it in the bin folder...
i tried adding static-libgcc doesn't work on Code::Blocks but on Visual Studio i get this error
LINK : fatal error LNK1104: cannot open file 'static-libgcc.obj'
-
It's a linker option. You need to put "-static-libgcc" where CodeBlocks wants you to put additional linker options.
The command needs to be renamed to "-static" on newer GCC versions. I doubt you have a "newer" version though.
-
The command needs to be renamed to "-static" on newer GCC versions.
What newer versions? -static-libgcc was introduced in GCC 3.0, it's still supported in GCC 4.6.0, and it'll be supported in GCC 4.7.0.
Furthermore, -static and -static-libgcc are not equivalent. The former makes the linker link statically whatever it can, the latter makes the linker link statically only the libgcc.
-
i tried adding -static-libgcc...it stills says the .dll is missing.
EDIT: I installed the newest MinGW and now it's fixed. Thanks for the help :)
-
The reason I said "-static" needs to be used on newer versions is from personal experience.
I've had my SFML 1.6 projects compile without needing additional DLLs on Windows with my initial MinGW tool chain that came with my IDE;
but, after updating to the latest SFML 2 and MinGW version, the "-static-libgcc" option was not enough and "-static" was.
-
Apparently you were linking to a dynamic library which was linked with dynamic libgcc. Since you had a static version of that library, too, -static "fixed" your "problem" (if you didn't have a static version of that library, -static would be of no avail). It doesn't change the fact that -static-libgcc is the proper way to link libgcc statically, though.
-
I should have not used the word "renamed" to describe to the user that he needs to use "-static" and not "-static-libgcc".
They're separate parameters that have existed for many previous versions. My goal was just to help him weed the dependencies out of his application.