Question

I’m having a weird problem with making an SFML2 application. I’m using Clang++ from the Repositories as well as libc++ (both updated today). SFML2 was also updated from the SVN repo. I’m using the latest version of Kubuntu. I also had the same problem when I last tried about a month ago with the then up-to-date repositories.

The parameters I’m passing through to the compiler for c++11 and stdlib are: -std=c++11 -stdlib=libc++

Here’s the full version of what I’m calling:

clang++ -std=c++11 -stdlib=libc++ main2.cpp -o main -L/home/jonathan/OpenSource/sfml/SFML-Build/lib/ -I/home/jonathan/OpenSource/sfml/SFML/include/ -lsfml-system -lsfml-window -lsfml-graphics -v

When I try to compile the application, I get a linking error from Clang :

/tmp/main2-stOJMp.o: In function `main':
main2.cpp:(.text+0x108): undefined reference to `sf::Window::create(sf::VideoMode, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int, sf::ContextSettings const&)'

All the application does (currently) is create a RenderWindow. It’s just a test application, but for most SFML2 functions I use, there will be some linking problem like this. If I don’t use libc++, the program compiles perfectly fine.

From what I can tell, if I include the -stdlib=libc++, it doesn’t search the SFML2 lib folder for the SFML2 libraries to correctly link with.

When I use the -v command for the invocation with Clang, here is the ld call:

"/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o main /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbegin.o -L/home/jonathan/OpenSource/sfml/SFML-Build/lib/ -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. -L/lib -L/usr/lib /tmp/main2-kOZbfN.o -lsfml-system -lsfml-window -lsfml-graphics -lc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o

And if I don’t use -stdlib=libc++…

"/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o main /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbegin.o -L/home/jonathan/OpenSource/sfml/SFML-Build/lib/ -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. -L/lib -L/usr/lib /tmp/main2-2IOIxv.o -lsfml-system -lsfml-window -lsfml-graphics -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o

So, In case I’ve confused people: if I use libc++ with Clang, I get the above error from the first ld call. If I don’t use it, the second ld call goes through perfectly fine and the application runs successfully.

The reason I’m using libc++ is because I want to use the Threading from C++11. Without it, I get a ton of errors from the GNU C++ standard library my computer has. I won’t post the error list for this, as it’s huge and not relevant to this problem.

Does anyone have any clue as to how I might be able solve the SFML2 problem? I’d rather not use the pthreads library if I don’t have to.

Answer 1

The SFML2 library has been compiled against some C++ library other than libc++ (perhaps libstdc++?). To correct, recompile SFML2 with -stdlib=libc++, and be sure the linker sees -stdlib=libc++ when linking SFML2 to your application.

The key to debugging this is noting that the linker is looking for sf::Window::create with std::__1 symbols. And libc++ mangles things with std::__1. But other std::libs mangle things with just std. This is a safety feature to keep you from accidentally mixing std::string from two different std::libs and ending up with a run time error instead of a link time error.