CODEWITHSUNDEEP
c++sfml
user4500878
user4500878

Reputation:

The procedure entry point _ZSt24__throw_out_of_range_fmtPKcz could not be located in the dynamic link library sfml-graphics-2.dll

Today I decided to download, install, and attempt to use SFML 2.2. I also downloaded Code::Blocks with the MinGW compiler. I set up everything and installed everything correctly (or so I thought) and tried to run a sample code to see if it would work:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(shape);
        window.display();
    }

    return 0;
}

The code compiled correctly although trying to run it an error message box appears saying "The procedure entry point _ZSt24__throw_out_of_range_fmtPKcz could not be located in the dynamic link library sfml-graphics-2.dll". I searched the web but didn't find anything related to this problem, so I came here searching for help. Thanks to further answers.

Upvotes: 8

Views: 8186

Answers (3)

Jnj
Jnj

Reputation: 1

It's essentially stating that your compiler is different from the one that SFML used.

You can solve this by downloading the specific version for each. For CodeBlocks, you just download(mingw16.01): http://www.codeblocks.org/downloads/26

For SFML, you just download GCC 4.9.2 TDM (SJLJ): https://www.sfml-dev.org/download/sfml/2.4.2/

Upvotes: 0

myQwil
myQwil

Reputation: 502

This isn't a direct solution, but a workaround would be to try static linking. It looks like SFML's tutorial talks about this, and it involves adding SFML_STATIC to your #defines section. Your exe's will be larger, but they'll also be more independent.

I had the same problem and static linking worked, although I was using mingw-w64 i686 alongside cmake. You would download SFML's source code, and then in the cmake settings, you would:

  • Choose the source and build folders
  • Click 'Configure' and for the generator, select "CodeBlocks - MinGW Makefiles"
  • turn off BUILD_SHARED_LIBS
  • turn on SFML_BUILD_EXAMPLES and SFML_USE_STATIC_STD_LIBS
  • change CMAKE_BUILD_TYPE to Debug (optional, for helpful error messages)
  • click 'Configure', then 'Generate'

There will be a .cbp file in the build folder. Also, the examples might tell you either the 'resources' folder or openal32.dll are missing, so you just need to add those to the examples in your build folder.

Upvotes: 0

PaulMcKenzie
PaulMcKenzie

Reputation: 35455

The main reason for this issue is the import libraries for the DLL's were created for a different version of the DLL you're using.

When you built the application, you used an import library so that the linker will find the SFML functions that your application is calling. However, the DLL itself does not contain one or more of the functions that the import library has stubs for.

When creating an application that implcitly loads a DLL entails a 3 step process:

  1. Compiling the code
  2. Linking the code
  3. Running the code

All the compiler cares about is that the program is syntactically correct. This worked without error.

The linker stage determines if the functions you're calling actually exist. This is where things get tricky, since the function stubs exist in the import library, and that will satisfy the linker. The import library tells the linker, "yes, this function is here in this DLL, so trust me". This also worked without error for you

(Note that this is different in a non-DLL scenario, where the linker will actually look for the function itself, not a stub).

However, the actual functions themselves are in a different module (DLL), and the only time your application can determine their existence is when you run the program. This is where you're stuck right now.

So the thing you should do first is make sure that the import libraries you're using when building your application match up with the DLL's that you're loading at runtime. If you still get the error, contact where you got the DLL's and inquire how to get the proper import libraries.

In addition, there are ways to create an import library from a DLL, if for some reason you can't get the import libraries. I don't know all the details of how to do this manually for MingW, but the information should be available online somewhere.

Upvotes: 6

Related Questions