Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Unresolved externals  (Read 4526 times)

0 Members and 2 Guests are viewing this topic.

Magnorph

  • Newbie
  • *
  • Posts: 1
    • View Profile
Unresolved externals
« on: October 08, 2015, 02:31:03 am »
So I recently installed visual basic 2015 and wanted to set up SFML 2.3.2. After going through everything in this link perfectly: http://www.sfml-dev.org/tutorials/2.3/start-vc.php. I still get LNK1120 and LNK2019 errors. I've looked around for solutions but haven't found one yet. I have my debug static but whenever I use -s-d.lib format I only get more errors. I have no idea what to do at this point and any help would be amazing. Thanks.

Austin J

  • Newbie
  • *
  • Posts: 29
    • View Profile
    • Email
Re: Unresolved externals
« Reply #1 on: October 08, 2015, 03:25:08 am »
I wouldn't call this enough information. In a nutshell I believe with VS though the steps are -

1.) Add include directories
2.) Add lib directories ( make sure you have appropriate version for your build)
3.) Also add to your linker " sfml-system-x-x.lib etc. " (appropiate to versions for your build)
4.) Since you're going with static, I believe you need to define SFML_STATIC. You should be able to add this to your preproccesor settings or you can add it into your source directly
Code: [Select]
#define SFML_STATIC
Assuming I have these steps right ( someone correct me if I'm wrong, I haven't used VS in ages) , are you sure you went through those steps?

If you're really having much trouble, someone here might be kind of enough to look at your project file themselves. I'd be willing but I don't have a Windows machine, so sorry but I cannot.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
Re: Unresolved externals
« Reply #2 on: October 08, 2015, 07:53:38 am »
Without providing any detailed errors we can't really help you.

My guess is that you didn't link (all of) SFML's dependencies despite it being mentioned in the tutorial.
4.) Since you're going with static, I believe you need to define SFML_STATIC. You should be able to add this to your preproccesor settings or you can add it into your source directly
Code: [Select]
#define SFML_STATIC
Never define SFML_STATIC in the code itself with #define.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Austin J

  • Newbie
  • *
  • Posts: 29
    • View Profile
    • Email
Re: Unresolved externals
« Reply #3 on: October 08, 2015, 06:30:57 pm »
Quote
Never define SFML_STATIC in the code itself with #define.

For his circumstance I agree, I suppose I should clarify I just meant it's possible to do that not that you should. I'm curious however, what would you propose if someone was using a development environment more like mine? I don't use an IDE, I use Vim, cmake, and make and that's about it. Obviously I'm not statically linking on Linux, but some people on Windows believe it or not don't use IDE's like VS or QtCreator either.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
Re: Unresolved externals
« Reply #4 on: October 08, 2015, 06:42:56 pm »
You define it in your CMake script with possibly an option to enable/disable static linking.
Actually if you use the FindSFML.cmake module script and define SFML_STATIC_LIBRARIES (as explained in the FindSFML.cmake file itself), SFML_STATIC will be set automatically.

There's always some sort of "project settings", be it a makefile, a CMake file, an IDE project file or even just the raw command line that will allow you to define the SFML_STATIC project wide and as such there's (in my opinion) no use case where #define SFML_STATIC is valid.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Unresolved externals
« Reply #5 on: October 08, 2015, 07:52:48 pm »
Where would you even write #define SFML_STATIC in your code? You have to write a header that every other file includes, which is 1. not very beautiful and 2. easily forgettable, which then causes non-obvious linker errors...

The configuration environment (i.e. CMake or the IDE) is the right place for configuration settings ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Austin J

  • Newbie
  • *
  • Posts: 29
    • View Profile
    • Email
Re: Unresolved externals
« Reply #6 on: October 08, 2015, 08:03:01 pm »
Quote
You define it in your CMake script with possibly an option to enable/disable static linking.
Actually if you use the FindSFML.cmake module script and define SFML_STATIC_LIBRARIES (as explained in the FindSFML.cmake file itself), SFML_STATIC will be set automatically.

There's always some sort of "project settings", be it a makefile, a CMake file, an IDE project file or even just the raw command line that will allow you to define the SFML_STATIC project wide and as such there's (in my opinion) no use case where #define SFML_STATIC is valid.

Haha, I suppose I should've expected that answer. Yes and as a matter of fact I already use FindSFML.cmake in any SFML project I use. Sometimes when using Boost libraries one must #define <something here> and indeed I always do it in the "project settings" of cmake, qmake, IDE settings, whatever. I gag a little at the Irrlicht site when they use #pragma to link their library in the tutorial programs.

Where I'm disagreeing is when you say "never". I myself indeed never need to use #define directly in the source. The only exception I can think of for myself is using some of the stb libraries. STB libraries to me are actually examples where not using some form of a project setting for preprocessor defines is understandable. So I do think that using #define in your source is very rarely appropriate, but I won't say it's never appropriate in my honest opinion.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Unresolved externals
« Reply #7 on: October 08, 2015, 08:05:40 pm »
What do you mean with STB libraries, and why is the situation different for them?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Austin J

  • Newbie
  • *
  • Posts: 29
    • View Profile
    • Email
Re: Unresolved externals
« Reply #8 on: October 08, 2015, 08:12:08 pm »
Forgive me, maybe you haven't heard of stb  :P

https://github.com/nothings/stb

If you haven't come across stb before and you're interested in what is go ahead and check out that git repo.

I myself have never made serious use of his "libraries", but in many of his header files he makes use of #define in the source directly for settings etc.

I understand this is an odd example, and that's precisely why I'm saying I agree not using preprocessor settings in what ever form of project manager you have is a bad idea, but I'm not convinced that 100% of people out there don't have a good reason to make use of #define directly in their source. I feel there's bound to be the rare exception.

I'm dragging this a bit out of scope though I apologize. In SFML's case where it's simply SFML_STATIC in mind, I can't imagine a reason to define it in source and you're right I shouldn't have even mentioned it in my original post. When I say I believe there's a rare exception I mean with using #define in general not specifically for SFML.
« Last Edit: October 08, 2015, 08:15:03 pm by Austin J »

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Unresolved externals
« Reply #9 on: October 08, 2015, 08:22:11 pm »
I know it, in fact SFML uses STB for its image loading ;)

But I didn't see anything special with this library, that's why I asked. I think the author just wants to keep everything as self-contained and minimal as possible, without tons of external configuration scripts. Every makefile and meta-build system incurs another dependency for those who want to use the library.

Many libraries use #define and #ifdef for conditional compilation and linkage, that's perfectly fine. But when using libraries in your project, it's usually easier to set configurations globally and not in code. Of course, there are no hard borders, in the end it's a matter of achieving the right things with minimal effort.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Austin J

  • Newbie
  • *
  • Posts: 29
    • View Profile
    • Email
Re: Unresolved externals
« Reply #10 on: October 08, 2015, 08:32:48 pm »
I know it, in fact SFML uses STB for its image loading ;)

But I didn't see anything special with this library, that's why I asked. I think the author just wants to keep everything as self-contained and minimal as possible, without tons of external configuration scripts. Every makefile and meta-build system incurs another dependency for those who want to use the library.

Many libraries use #define and #ifdef for conditional compilation and linkage, that's perfectly fine. But when using libraries in your project, it's usually easier to set configurations globally and not in code. Of course, there are no hard borders, in the end it's a matter of achieving the right things with minimal effort.

With that friend I can't disagree with anything you say there. Interesting to learn that SFML actually uses STB though, I had no idea! I don't know about stb's image loading, but I remember that stb_tilemap had a lot of configuring done through #define in its source. This was understandable in my opinion because he had to create a whole UI and tilemap system without knowing for sure what settings the user wanted (i.e the max tilemap size) and without any of his own rendering implementation. That's a very niche scenario though.