c++ - 使用 Clang、libc++ 和 c++11 制作 SFML2 应用程序。对 SFML 库的 undefined reference

Question

我在制作 SFML2 应用程序时遇到了一个奇怪的问题。我正在使用存储库中的 Clang++ 以及 libc++(均在今天更新)。 SFML2 也从 SVN 存储库更新。我正在使用最新版本的 Kubuntu。当我大约一个月前最后一次尝试使用当时最新的存储库时，我也遇到了同样的问题。

我传递给 c++11 和 stdlib 编译器的参数是:-std=c++11 -stdlib=libc++

这是我调用的完整版本:

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

当我尝试编译应用程序时，我收到来自 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&)'

应用程序所做的(当前)是创建一个 RenderWindow。这只是一个测试应用程序，但对于我使用的大多数 SFML2 函数，都会有一些像这样的链接问题。如果我不使用 libc++，程序编译得很好。

据我所知，如果我包含 -stdlib=libc++，它不会在 SFML2 lib 文件夹中搜索要正确链接的 SFML2 库。

当我使用 -v 命令调用 Clang 时，这里是 ld 调用:

"/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

如果我不使用 -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

所以，以防我让人们感到困惑:如果我将 libc++ 与 Clang 一起使用，我会从第一次 ld 调用中得到上述错误。如果我不使用它，第二个 ld 调用会非常顺利，应用程序会成功运行。

我使用 libc++ 的原因是因为我想使用 C++11 的线程。没有它，我的计算机上的 GNU C++ 标准库就会出现大量错误。我不会为此发布错误列表，因为它很大而且与这个问题无关。

有人知道我如何解决 SFML2 问题吗？如果不需要，我宁愿不使用 pthreads 库。

Answer 1

SFML2 库是针对 libc++ 以外的某些 C++ 库(也许是 libstdc++？)编译的。要更正，请使用 -stdlib=libc++ 重新编译 SFML2，并确保链接器在将 SFML2 链接到您的应用程序时看到 -stdlib=libc++。

调试的关键是注意链接器正在寻找带有 std::__1 符号的 sf::Window::create。并且 libc++ 破坏了 std::__1 的内容。但其他 std::libs 仅使用 std 就搞砸了。这是一项安全功能，可防止您意外混合来自两个不同 std::lib 的 std::string 并以运行时错误而不是链接时错误结束。