So... I've been trying to solve these linker errors for a couple of days now, I've googled but found nothing that helps and now I've realized that I can't solve it by myself.
Also, if I haven't posted enough of my code... just tell me, I could pastebin everything if that's necessery since I've got absolutely no idea how to solve this. But at least I think that the errors are related to the code-snippets I'll post here for now.
1>Game.obj : error LNK2019: unresolved external symbol "public: class sf::Texture __thiscall Textures::getTexture(int)" (?getTexture@Textures@@QAE?AVTexture@sf@@H@Z) referenced in function "public: int __thiscall Game::Initialize(void)" (?Initialize@Game@@QAEHXZ)
1>Player.obj : error LNK2019: unresolved external symbol "public: class sf::Sprite __thiscall Tile::getSprite(void)" (?getSprite@Tile@@QAE?AVSprite@sf@@XZ) referenced in function "public: virtual void __thiscall Player::move(class TileMap * &)" (?move@Player@@UAEXAAPAVTileMap@@@Z)
1>Player.obj : error LNK2019: unresolved external symbol "public: __thiscall Character::Character(void)" (??0Character@@QAE@XZ) referenced in function "public: __thiscall Player::Player(class sf::Texture &)" (??0Player@@QAE@AAVTexture@sf@@@Z)
1>TileMap.obj : error LNK2019: unresolved external symbol "public: void __thiscall Tile::draw(class sf::RenderWindow &)" (?draw@Tile@@QAEXAAVRenderWindow@sf@@@Z) referenced in function "public: void __thiscall TileMap::draw(class sf::RenderWindow &)" (?draw@TileMap@@QAEXAAVRenderWindow@sf@@@Z)
These are my beloved error, that's making my days a pain.
_player = new Player(_charTextures.getTexture(0));
vec_Textures is a std::vector<sf::Texture>, if that's relevant.
1 2 3 4 5 6 7 8 9 10 11
// Vector with all textures for NPC's and player characters
First thing i did before I started the project was to create a window and try it, and if it was because of that then my linker errors would have been related to sfml. And most likely they'd have been something like "missing __dll import", if my memory isn't all wrong.
I've also tried to create a new project and added dependencies and all that stuff from scratch - still the same errors, so it has something to do with my code.
And in all *.cpp files I #include the header/s that I need.
I'm starting to think that I'd be better off just redoing everything from scratch...
Things need to be linked in the correct order, too. Your error could be a result of out-of-order linking. If the sf library is linked in before Game, for instance, the symbols from sf needed by Game may not have been pulled in. So you would need to make sure that Game (whether it is a .o or a .a [or .obj or.lib]) is is before your sf library in your linking command.
Your error smells a lot like a linking problem I have had in the past. It involved compiling my code into archives (libraries) and then linking them into my executable. I was building using *nix makefiles, and it looks like you are using an IDE, so my situation may not have anything to do with yours. If you are not archiving (making libraries of) your code, then this will not apply directly. But I'll explain it anyway, and you can ignore it if you so desire, or maybe it will spark an idea of how to solve your problem.
Assuming that your object files contain code for single classes and are named for their contained classes (e.g. Game.o contains class Game), your error message shows that the following dependencies exist:
Now, assume that you created archives (libraries) to contain these .o files. The archive file libGame.a contained Game.o, and so on. (I believe that would be Game.lib in Windows terminology).
Now, assume your link command looks something like this (-lName means search for object files in archive "libName.a")
LINK main.o -lTextures -lGame -lTile -lTileMap -lCharacter -lPlayer
Yeah there's stuff missing, but this is the important stuff for this discussion. After main.o is pulled into the executable, it has dependencies on Game, Player and TileMap. Now the linker looks at each of the libraries in order to see what it needs to pull in.
The linker looks at libTextures.a and sees nothing that it currently needs (Game hasn't been pulled in yet), so it ignores the library. Then it looks at libGame.a and pulls in Game.o (needed by main.o). Then the linker looks at Tile and sees that nothing that it contains currently needs it (TileMap and Player have not been pulled in yet), so nothing is pulled in. This goes on for the rest of the listed archives.
At the end, Game.o, TileMap.o and Player.o are pulled in because they were required by main.o. The other .o files, however, are not pulled in because there was no dependency on them at the time that they were checked. At the end of linking, the dependencies in your list remain unresolved.
If the order of the archives in the link command were reordered:
LINK main.o -lGame -lTextures -lTileMap -lPlayer -lCharacter -lTile
the problem will be solved.
This is a little bit simplified, but I think you can get the point.