Linking in Linux

[hatfarm]

Hey everyone.  I've been using SFML on Windows for the past 6 months, but I've been using CMake for my build system so that I could ensure that I could build it in Linux at least.  So, I've hit a milestone in my engine and I want to ensure that everything works in Linux as well, because I would like to be able to release Windows/Linux at least.  Anyway, I've fixed all the issues with my code, and I've even got the .a library linking, but unfortunately g++ is having issues linking the libraries linked to by SFML (for instance x11).  I build SFML with these directions:

http://sfmlcoder.wordpress.com/2011/08/16/building-sfml-2-0-with-make-for-gcc/

I added all of the libraries needed, but for whatever reason g++ isn't finding them when it goes to link my application.  Anyone have any ideas on how to possibly resolve this? 

[Tank]

Please post the error messages ld produces. The build commands would also be helpful (make VERBOSE=1).

[hatfarm]

Here's the tail end of the linking errors:

Texture.cpp:(.text+0x18be): undefined reference to `glGetTexImage'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(Texture.cpp.o): In function `sf::Texture::operator=(sf::Texture const&)':
Texture.cpp:(.text+0x1bec): undefined reference to `glDeleteTextures'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(TextureSaver.cpp.o): In function `sf::priv::TextureSaver::TextureSaver()':
TextureSaver.cpp:(.text+0x13): undefined reference to `glGetIntegerv'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(TextureSaver.cpp.o): In function `sf::priv::TextureSaver::~TextureSaver()':
TextureSaver.cpp:(.text+0x35): undefined reference to `glBindTexture'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(GLCheck.cpp.o): In function `sf::priv::glCheckError(char const*, unsigned int)':
GLCheck.cpp:(.text+0x34): undefined reference to `glGetError'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(GLCheck.cpp.o): In function `sf::priv::ensureGlewInit()':

The funny thing is, I specifically link to the glew.a library from the extlibs directory.  Any suggestion?  I didn't just sudo apt-get install sfml-dev because I think I read that 2.1 isn't there yet, and I'd like to be working off of 2.1.  Any help here would be greatly appreciated.

[Jebbs]

Here's the tail end of the linking errors:

Texture.cpp:(.text+0x18be): undefined reference to `glGetTexImage'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(Texture.cpp.o): In function `sf::Texture::operator=(sf::Texture const&)':
Texture.cpp:(.text+0x1bec): undefined reference to `glDeleteTextures'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(TextureSaver.cpp.o): In function `sf::priv::TextureSaver::TextureSaver()':
TextureSaver.cpp:(.text+0x13): undefined reference to `glGetIntegerv'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(TextureSaver.cpp.o): In function `sf::priv::TextureSaver::~TextureSaver()':
TextureSaver.cpp:(.text+0x35): undefined reference to `glBindTexture'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(GLCheck.cpp.o): In function `sf::priv::glCheckError(char const*, unsigned int)':
GLCheck.cpp:(.text+0x34): undefined reference to `glGetError'
/home/hatfarm/SFML-2.1//lib/libsfml-graphics-s.a(GLCheck.cpp.o): In function `sf::priv::ensureGlewInit()':

The funny thing is, I specifically link to the glew.a library from the extlibs directory.  Any suggestion?  I didn't just sudo apt-get install sfml-dev because I think I read that 2.1 isn't there yet, and I'd like to be working off of 2.1.  Any help here would be greatly appreciated.

Those are OpenGL functions, not Glew ones. Looks like you aren't linking to OpenGL.

Doesn't linking with the graphics module automatically link your program to OpenGL though?

[OniLinkPlus]

Doesn't linking with the graphics module automatically link your program to OpenGL though?

Not if he's linking statically.

[hatfarm]

I am linking statically, when I tried to use the so.2.1 files, it said that it didn't have a build option (or something like that) for those libraries.  How do I go about linking OpenGL then?  Would I be better off using the dynamic libraries?

[Tank]

-lGL

[hatfarm]

So, it's not linking any of the libraries that are needed by SFML.  Is there anywhere I can find the "-l"s that I need to build all of it.  Is there any easy way to do that in CMake?  Thanks for all your help.

[eXpl0it3r]

If you're linking things statically, you'll have to link against SFML and all its dependencies. You can find a list of them here.
And no there isn't really an easy way to do it (afaik).

[Ixrec]

For me, using CMake to build my program (not just SFML) magically solved all of these linking problems. All I had to do was make my program into one of SFML's example programs by modifying the relevant CMake files. It was easy to guess how since those files are so simple.

[eXpl0it3r]

For me, using CMake to build my program (not just SFML) magically solved all of these linking problems.

Are you linking statically as well?
Dynamic linkage will be much easier, yes.

[Ixrec]

Yes mine's all static (unless you count the audio libraries).

[hatfarm]

The problem I'm having is that I already wrote my CMake files and didn't have any issues with Windows, but now with Linux I have to link all of these libraries separately.  I've looked through the SFML CMake files and I can't find where the variables are actually defined.  There is, for instance, the "OPENGL_INCLUDE_DIR" but I cannot find where that is defined.  I actually wrote a python script to search for that in all .txt files under the main SFML directory(and subdirectories) and was unable to find it.  Any recommendations?

[Laurent]

This kind of variables are defined by the find_package(XXX) calls.

[Ixrec]

That's why I made my program pretend to be one of SFML's examples.  Just go into the examples folder, modify the CMake file there which essentially just lists subfolders (after making a new subfolder for your program), then look at the CMake file that each example program's subfolder has and make a version of it for your program.  The files are pretty self-explanatory.

I have no idea if this was the optimal approach but it was very quick and easy and it hasn't broken for me yet.