CODEWITHSUNDEEP
c++windowsdllruntime-error
Iron Attorney
Iron Attorney

Reputation: 1070

"The procedure entry point.... could not be located" error

I have been setting up my application to compile on windows 8, using mingw32 (i686-w64-mingw32 to be precise). I have set up the toolchain and links etc correctly as far as I can tell, and the app compiles and runs inside codeblocks. When I try to run the release version outside of codeblocks. My app depends on libsndfile-1, csound, and a number of the SDL2 libraries. Libsndfile and csound are statically linked, SDL2 is dynamically linked. In my project folder, my SDL2 DLL's are located in \GUI\bin.

When trying to run the .exe outside of codeblocks... If I stick the DLL's in a folder with the same relative filepath to the .exe as in the project folder (ie \GUI\bin), I get an error messages telling me it can't find the SDL2 DLL's

If I stick the DLL's in the same folder as the .exe, I get the following message:

The procedure entry point _ZNSt7__cxx1112basic_stringlcst11char_traitslcSt11char_traitslcESalcEE10_M_replaceEjjPKcj could not be located in the dynamic link library C:\Users\Peter\Documents\SDLGUIApp\bin\Release\SDL GUI.exe

I've done some research, and I'm struggling to find info that is relevant to my situation. Seeing as it drops the "can't find DLL's" error messages when I move them to the same folder as the .exe, then I'm guessing either it finds them in the same folder, and this error is caused by something else, or it is even less happy with them being moved to the same folder than it is with them in the 'correct' place. Either way, I'm stumped!

Any help will be much appreciated!

Pete

EDIT:

Some sources I've found suggest that the order in which I link to the libraries might cause similar (though not identical) errors. I have tried shuffling them around, but nothing I've tried make it better. Here is how I am linking:

In other linker options:

-lmingw32 -lSDL2main -lSDL2 -lSDL2_image -lSDL2_mixer -lSDL2_ttf

In link libraries:

C:\Program Files\Libraries\Csound6\bin\csound64.lib C:\Program Files\Libraries\libsndfile32\lib\libsndfile-1.lib

A look at codeblock's build log suggests it links the "other linker options" first. I assume this, because one of the last sections from the build log says this:

-lmingw32 -lSDL2main -lSDL2 -lSDL2_image -lSDL2_mixer -lSDL2_ttf -s -mwindows -lmingw32 "C:\Program Files\Libraries\Csound6\bin\csound64.lib" "C:\Program Files\Libraries\libsndfile32\lib\libsndfile-1.lib"

I'm not sure what the -s means, or why it mentions -lmingw32 twice.

EDIT:

Sorry, a further edit... I have read about how similar errors occur from either not having a main function, or from having the wrong build type selected in codeblocks build options (typically it is the difference between Console or GUI application set under the type option). I have tried exploring these ideas, but I definitely have an "int main()" function, the main.cpp is included in both the debug and release builds, and I have "console application" selected as build type for both debug and release, so as far as I can tell, the error isn't because of any of these.

Upvotes: 0

Views: 2562

Answers (1)

paulsm4
paulsm4

Reputation: 121599

  1. I don't think the problem is "dll not found". Rather, I think it's "function name not found".

  2. Specifically, if you were coding in "C", you'd expect to link to function names like "myFunc()".

    If you were coding in C++, you'd instead expect "mangled names" like "_ZNSt7__cxx1112basic_stringlcst11char_traitslcSt11char_traitslcESalcEE10_M_replaceEjjPKcj".

  3. In other words, I think you might have inadvertently compiled some C functions as though they were C++, and the linker is looking for the "mangled name" instead of the "actual name".

SUGGESTIONS:

a. See if you recognize "_ZNSt7__cxx1112basic_stringlcst11char_traitslcSt11char_traitslcESalcEE10_M_replaceEjjPKcj" as being a function you might have written. If so, make sure it has a ".cpp" (C++) extension; and make sure you're including the object file (.o or .obj) in your link command.

b. Otherwise, make sure you #include <xyz> the appropriate header (.h) file for every external call you're making.

c. Failing all else, write a simple "hello world" 5 line SDL2 program to verify that you can successfully compile, link and execute.

d. If the "hello world" fails, update your post with:

1. "hello world" source
2. "hello world" compile/link command
3. Exact error message

These links might also help:

Upvotes: 1

Related Questions