SFML community forums

Help => General => Topic started by: Culinary on November 18, 2015, 01:23:44 pm

Title: Unresolved external symbol: __imp__*
Post by: Culinary on November 18, 2015, 01:23:44 pm

Using Visual Studio 2012, downloaded SFML 2.3.2 Visual C++ 11 (2012).

Project Options, Release Configuration:

C/C++
 -- General
     Additional Include Dependencies: Z:\SFML-2.3.2\include;

-- Preprocessor
    Preprocessor Definitions: SFML_STATIC;

Linker
-- General
     Additional Library Directories: Z:\SFML-2.3.2\lib;

-- Input
     Additional Dependencies: sfml-graphics-s.lib;sfml-window-s.lib;sfml-system-s.lib;sfml-main.lib;

main.cpp:

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;
}
 

Errors:

Quote

error LNK2001: unresolved external symbol __imp__glReadPixels@28
error LNK2001: unresolved external symbol __imp__glBlendFunc@8
error LNK2001: unresolved external symbol __imp__glClear@4

...List goes on.

Title: Re: Unresolved external symbol: __imp__*
Post by: Laurent on November 18, 2015, 01:29:53 pm

http://www.sfml-dev.org/tutorials/2.3/start-vc.php

Title: Re: Unresolved external symbol: __imp__*
Post by: Culinary on November 18, 2015, 01:36:35 pm

Ah I didn't realise there were new dependencies for 2.3.

Added these and it worked:

Quote

opengl32.lib
freetype.lib
winmm.lib
gdi32.lib
jpeg.lib

Question though, why does this version of SFML use these dependencies as opposed to previous versions?

Title: Re: Unresolved external symbol: __imp__*
Post by: Laurent on November 18, 2015, 02:06:45 pm

If you search a little bit, you can find the corresponding discussion on the forum and/or github ;)

Short answer: it was ugly and non-conventional to stuff the dependencies directly into the SFML libraries.