undefined reference to sf::Window::setSize()

[BruceJohnJennerLawso]

Okay,

so I finally figured out how to link SFML on crunchbang linux properly!!! 

I compiled one of my basic SFML programs, specifically this one:

https://github.com/BruceJohnJennerLawso/xkcd-Now

Which works fine except for one function call, specifically sf::Window::setSize(sf::Vector2<unsigned int> const&)

If the line in question for that call is commented out, the program works fine, but when uncommented it causes an error at linking time, when it spits out this:

Now.cpp:(.text+0x455): undefined reference to `sf::Window::setSize(sf::Vector2<unsigned int> const&)'
 

After doing a little research, it sounds as if this problem could be caused by different function prototypes & definitions.

In the SFML header files that I am using, I have

    ////////////////////////////////////////////////////////////
    /// \brief Change the size of the rendering region of the window
    ///
    /// \param size New size, in pixels
    ///
    /// \see getSize
    ///
    ////////////////////////////////////////////////////////////
    void setSize(const Vector2u& size);

I did compile SFML from scratch, so maybe its possible that this function was inadvertently changed at some point? (without updating the header file to match?)

[Nexus]

The signatures in SFML match perfectly, see here and here. It would not even be possible to build SFML otherwise.

So there's a configuration issue on your side. Link sfml-window (and make sure the version matches the headers). Start again from a clean point if necessary.

[BruceJohnJennerLawso]

The signatures in SFML match perfectly, see here and here. It would not even be possible to build SFML otherwise.

So there's a configuration issue on your side. Link sfml-window (and make sure the version matches the headers). Start again from a clean point if necessary.

Odd...

I checked the Github links to the function calls you posted, my source and header appears to match that exactly. I dont see any reason to rebuild from source in that case...

I believe I am linking sfml-window when I link the executable:

g++ Now.o -o xkcd-Now -lsfml-graphics -lsfml-window -lsfml-system

Is there anything else that could possibly be causing this error?

[BruceJohnJennerLawso]

Fixed. It appears I forgot to copy the newly built SFML .so files from the build folder when I built SFML from scratch. Oddly enough though, there were copies of SFML2.0 libs in there along with the 1.6 ones. No idea why though...

Apologies for the stupid problem 

[Nexus]

It appears I forgot to copy the newly built SFML .so files from the build folder when I built SFML from scratch.

Is there a reason why you don't use CMake and then make install, which automatically copies the headers and libraries to the chosen install path?

And delete SFML 1.6, it's severly outdated and there's really no point in using it anymore...

[BruceJohnJennerLawso]

It appears I forgot to copy the newly built SFML .so files from the build folder when I built SFML from scratch.

Is there a reason why you don't use CMake and then make install, which automatically copies the headers and libraries to the chosen install path?

Well that was what I did, but for some reason, it didnt appear to work.  I have no idea why

Now that I have the executable working, will it work on other computers? (possibly running different linux distros)

Will the end user need to manually link their copy of the program to the SFML lib files? That could be a headache, as both distros Ive tried so far only have SFML 1.6 in their repos. (Kubuntu and Crunchbang, specifically)

[Nexus]

You have to ship the SFML binaries, as the other user won't have them. You can either make a script that sets up the correct runtime paths, or hardcode relative paths in the executable using the -rpath linker option.

[BruceJohnJennerLawso]

You have to ship the SFML binaries, as the other user won't have them. You can either make a script that sets up the correct runtime paths, or hardcode relative paths in the executable using the -rpath linker option.

so basically some sort of script that detects where the sfml binaries normally go, then copies the 2.1 libs to that location? That probably could be done in some sort of bash script (maybe search for the outdated SFML 1.6 crap libs in order to find that location regardless of the operating system). I dont know much about scripting in Linux, but I know my terminal commands reasonably well, so maybe I can do that.

Would it be possible to statically link the libs?

So, the executable should run on any linux distro, provided that it can locate the libraries it needs? (and the image assets of course)

[Jesper Juhl]

You may find this thread of interest (I think): http://en.sfml-dev.org/forums/index.php?topic=14587.0