SFML community forums

Help => System => Topic started by: Nexus on January 21, 2012, 12:53:01 am

Title: Linker error at sf::Time
Post by: Nexus on January 21, 2012, 12:53:01 am

Using Visual Studio 2010, I get strange linker errors when I compile the SFML Network module with dynamic (DLL) configuration.

Code: [Select]

3>Ftp.obj : error LNK2001: Unresolved external symbol ""public: static class sf::Time const sf::Time::Zero" (?Zero@Time@sf@@2V12@B)".
3>SocketSelector.obj : error LNK2001: Unresolved external symbol ""public: static class sf::Time const sf::Time::Zero" (?Zero@Time@sf@@2V12@B)".
3>TcpSocket.obj : error LNK2001: Unresolved external symbol ""public: static class sf::Time const sf::Time::Zero" (?Zero@Time@sf@@2V12@B)".
I don't see a mistake in the code, sf::Time has the SFML_API macro, and Zero is properly defined in Time.cpp. If I interpret the Dependency Walker output correctly, this symbol is exported in sfml-system-d-2.dll. With MinGW/g++, SFML compiles fine.

Can anybody confirm this? I've also found a similar problem (http://stackoverflow.com/questions/2479784/exporting-static-data-in-a-dll) on StackOverflow...

Title: Linker error at sf::Time
Post by: Breakman79 on January 21, 2012, 02:07:18 am

I just updated my copy from git and I get that same error from sfml-network and this one from sfml-audio:

Code: [Select]

SoundStream.obj : error LNK2019: unresolved external symbol "public: static class sf::Time const sf::Time::Zero" (?Zero@Time@sf@@2V12@B) referenced in function "private: bool __thiscall sf::SoundStream::FillAndPushBuffer(unsigned int)" (?FillAndPushBuffer@SoundStream@sf@@AAE_NI@Z)

Title: Linker error at sf::Time
Post by: Laurent on January 21, 2012, 10:37:01 am

It's fixed, thanks for the quick feedback.

On a side note, it also answers a question that I've always asked to myself (-> how it could work with a single export macro for all modules) :)

Title: Linker error at sf::Time
Post by: Nexus on January 21, 2012, 10:53:52 am

Thank you for the fast fix! :)

I didn't expect it to be that complex. If I understand correctly, you now use __declspec(dllexport) only for the currently compiled module, and __declspec(dllimport) for modules on which the current one depends.

Title: Linker error at sf::Time
Post by: Laurent on January 21, 2012, 11:36:45 am

Quote

If I understand correctly, you now use __declspec(dllexport) only for the currently compiled module, and __declspec(dllimport) for modules on which the current one depends.

Correct ;)