link problems between stl-port and SFML

Started by
2 comments, last by Juanxo 14 years, 1 month ago
Hi all: I'm trying to port some code from SDL to SFML, and I'm getting some problems with the linker. The code I'm trying to port is a collada loader (with Assimp). If I include and link only Assimp with SFML, I get a runtime exception (Access violation writing location 0xcdcdcdcd). I think this is because Assimp use stlport internally. But in the other hand, when I also include and link stlport, I get some linker errors:
error LNK2019: unresolved external symbol "public: void __thiscall sf::Window::Create(class sf::VideoMode,class stlp_std::basic_string<char,class stlp_std::char_traits<char>,class stlp_std::allocator<char> > const &,unsigned long,struct sf::WindowSettings const &)"
and
error LNK2019: unresolved external symbol "public: bool __thiscall sf::Image::LoadFromFile(class stlp_std::basic_string<char,class stlp_std::char_traits<char>,class stlp_std::allocator<char> > const &)" 
I think this is because SFML can't use stlport containers, but I can't figure out how to fix this issue. If someone knows how to solve this problem, please tell me because I'm going crazy. Note:While I was using SDL, I didn't have any issue (I think this is because SDL is more C oriented API) Thx
Advertisement
Simplest solution? Don't use stlport.

Any decent compiler (MSVC 7+, GCC 4+, etc.) comes with a full standard library implementation - use that instead.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Did you add SFML_DYNAMIC to the preprocessor commands?

reference
Thx both.

I haven't used dynamic linking, so I think it isn't necessary SFML_DYNAMIC. I'll go with the standard library of the compiler, but I don't know what is causing this problem

This topic is closed to new replies.

Advertisement