Visual Studio 2013 and MinGW, linker with unresolved externals

[Contadotempo]

Hey guys

I'm trying to compile an example project with the static SFML 2.1 libs using both compilers mentioned in the title.
For some reason both compilers give me the following unresolved externals for the example source code I'll post next:

Code: [Select]

error LNK2001: unresolved external symbol __imp__glBlendFunc@8
error LNK2001: unresolved external symbol __imp__glClear@4
error LNK2001: unresolved external symbol __imp__glClearColor@16
error LNK2001: unresolved external symbol __imp__glColorPointer@16
error LNK2001: unresolved external symbol __imp__glDisable@4
error LNK2001: unresolved external symbol __imp__glDrawArrays@12
error LNK2001: unresolved external symbol __imp__glEnable@4
error LNK2001: unresolved external symbol __imp__glEnable@4
error LNK2001: unresolved external symbol __imp__glEnableClientState@4
error LNK2001: unresolved external symbol __imp__glLoadMatrixf@4
error LNK2001: unresolved external symbol __imp__glLoadMatrixf@4
error LNK2001: unresolved external symbol __imp__glMatrixMode@4
error LNK2001: unresolved external symbol __imp__glMatrixMode@4

The source code is from the tutorial example:

Code: [Select]

#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;
}
I'm linking against: sfml-audio-s.lib, sfml-graphics-s.lib, sfml-window-s.lib, sfml-system-s.lib, on Release settings. SFML_STATIC is defined in the Preprocessor. I've recompiled SFML from source for each compiler, the linker errors are the same (or very similar).

I don't know what I could be missing here. They seem to be related to openGL, but I'm not using it directly anywhere, well maybe except for SFML itself. Any heads up?

Thank you for your time.

EDIT:
I think I should mention that I was previously using SFML 2 with windows 7, everything was working fine. Now I've reformatted to windows 8.1 and this started to happened. Graphics drivers are up to date as well.

[eXpl0it3r]

I presume you've built SFML yourself from the latest source (thus actually not 2.1), because as of late one now needs to link all the dependencies manually with static libraries, as one always should have, thus you'll have to link against opengl, glew, etc. For more details see the original discussion.
The tutorial will be updated for the next release, everyone using the source directly should be aware of "undocumented" changes.

[Contadotempo]

Ah, that makes sense. Thanks for the quick reply.

everyone using the source directly should be aware of "undocumented" changes.

I usually am with SFML but since 2.1 came out I've slacked off a bit. 

EDIT:
Ok, done. This is my dependency list for Visual Studio 2013:

Code: [Select]

sfml-audio-s.lib
sfml-graphics-s.lib
sfml-window-s.lib
sfml-system-s.lib
glew.lib
opengl32.lib
freetype.lib
jpeg.lib
ws2_32.lib
gdi32.lib
winmm.lib
Isn't this a bit overkill? And I'm missing openAL there since I'm not using sounds. Really considering using dynamic libs to be honest.

[eXpl0it3r]

Why should it be overkill? SFML depends on a few libraries, thus one has to link them when choosing static linkage.

Well if you're not using sounds then you might not want to link against sfml-audio either, also you can remove ws2_32 (winsocks) since you're not using the network module.

[binary1248]

Isn't this a bit overkill? And I'm missing openAL there since I'm not using sounds. Really considering using dynamic libs to be honest.

Using dynamic libraries just so you don't have to type a few more lines into your library list (which is a project setting and only has to be done once) doesn't make any sense. The dynamic libraries also link against those libraries, so in the end, if you disregard the differences between static linking and dynamic linking you really are only saving yourself those few lines of typing.

If you think this bloats your executable, there are many other libraries that might get linked to your application without you even noticing. You have to remember, this list is only the complete set of libraries the linker will consider when looking for unresolved external symbols. Any half-decent linker will discard everything that doesn't need to be in the final executable anyway so worrying about size really doesn't make any sense either.

The converse might even be the case. Because you only use a subset of the SFML API in your application, the unused parts of it can be discarded by the linker when static linking. This is not possible without a bit of effort when distributing your application with the SFML .dlls.

[Contadotempo]

Thank you, I also came to believing that dropping statics libs because of the need to explicitly link a few dependencies, is a bit silly, and it actually makes more sense after reading a bit further.