SoundBuffer makes a crash on start

[sirckopo]

Good daytime, guys.

I've started making a game project on SFML yesterday and already got a big problem. /subj goes here/

First, it uses DUMB-based ModMusic snippet from CosmoScroll (https://code.google.com/p/cosmoscroll) to play BGM. It works well (although, got some playing/looping issues on gobus.mod).

Then I decided to add some sounds. Made a separate file, wrote loading code, inserted extern sf::SoundBuffer declarations to a header file, tried to build it... And on running a binary file there goes 'whoops':

Process returned -1073741515 (0xC0000135).

Even if I don't make any references to it, it still even fails till I comment out all SoundBuffer declarations.
Debugger shows that it doesn't even makes it to main(), so I can think that's something about memory.

What can I do with it? May it be related to the ModMusic code?

Windows 7 x64, SFML 2.1 (static), Code::Blocks 13.12, no Qt.

UPD: If it is about code, here it is.
UPD2: Yeah, it even makes a crash with SoundBuffer in the same module. So.
UPD3: Derp, it does a crash even without ModMusic, and WITHOUT ANY WINDOWS. Code updated again, gonna reinstall SFML right now.
UPD4: OK, it becomes serious. Reinstalled SFML, tried again with below code and still crashes. Now it's your turn.

#include <SFML/Audio.hpp>

sf::SoundBuffer sndWhatever;

int main()
{
    return 0;
}

UPDn: The problem is solved. Kids, always put libsndfile-1.dll and openal32.dll, even if you're linking your project statically.

[eXpl0it3r]

How should we know?!

Read the forum rules first and apply them to your post.

[sirckopo]

OK, I've got the most minimal and simple code with same effect.
Reinstalled SFML, double-checked project and build parameters:

mingw32-g++.exe -DSFML_STATIC -Wall -g -IC:\SFML-2.1\include -c E:\playground\main.cpp -o obj\Debug\main.o
mingw32-g++.exe -LC:\SFML-2.1\lib -o bin\Debug\playground.exe obj\Debug\main.o   -lmingw32 -luser32 -lgdi32 -lwinmm -ldxguid -lsfml-audio-s-d -lsfml-graphics-s-d -lsfml-window-s-d -lsfml-system-s-d -lsfml-main-d
Output file is bin\Debug\playground.exe with size 537.25 KB

Looks like the problem is on your side.

[Ixrec]

Some of SFML's resource classes cause problems like this when declared at global scope.  I know RenderWindows do that, so it wouldn't be surprising if this was something similar.  I don't remember the exact reasons why but I believe it boils down to global variables are evil, some property of C++ globals is responsible for this, and you shouldn't be using global resources anyway so it's not a real problem.

[sirckopo]

Oh dear SFML. YOU. KID. ME.



Let me explain... I use static version of SFML. And I'm linking it with STATIC version of audio library. And it still need A FRIGGIN DYNAMIC LIBRARY.
Thank you, my cats. Seems I need to go on bug tracker then.

P.S. Sorry for caps. That's because I've got a real bughurt.

[Ixrec]

How SFML itself is linked is entirely separate from how SFML's dependencies are linked.  OpenAL and libsndfile must be dynamically linked for license reasons.  This is not a bug, it's just how software libraries work.

Even if all of SFML's direct dependencies could be linked statically, you'd probably still be dynamically linking to a variety of OS-specific APIs and your machine's OpenGL implementation and maybe a C++ runtime and so on, which are things you would almost never want to try linking statically even if it was feasible.

[sirckopo]

How SFML itself is linked is entirely separate from how SFML's dependencies are linked.  OpenAL and libsndfile must be dynamically linked for license reasons.  This is not a bug, it's just how software libraries work.

Even if all of SFML's direct dependencies could be linked statically, you'd probably still be dynamically linking to a variety of OS-specific APIs and your machine's OpenGL implementation and maybe a C++ runtime and so on, which are things you would almost never want to try linking statically even if it was feasible.

Now it is all clear. Thank you for the explanation.
But why is there no any in the FAQ (only a few little mentions), wiki or tutorials?
That is an kind of insult to users who prefer linking statically. :c

[Ixrec]

I think the main reasons are that the details vary by platform (and they correctly try to keep the platform-specific details confined to the installation tutorials), and that it's just not all that important.  Everybody has to dynamically link against a bunch of other libraries for even the simplest program (whether they know it or not), so does it really matter if SFML doesn't try to provide a static build of OpenAL/libsndfile? Aside from allowing the average user do illegal things without even realizing it, I've heard that statically building those libraries on windows is either extremely hard or simply not supported.

Back when I was actively programming with SFML, I used static linking just to cut down on the total number of dlls.  The fact that I still had two left over was never an issue for me.