2

SFML2 アプリケーションの作成で奇妙な問題が発生しています。リポジトリの Clang++ と libc++ を使用しています (どちらも本日更新)。SFML2 も SVN リポジトリから更新されました。Kubuntuの最新バージョンを使用しています。約1か月前に当時の最新のリポジトリで最後に試したときも同じ問題がありました。

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 ライブラリが正しくリンクされるように SFML2 lib フォルダーが検索されません。

-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

したがって、私が人々を混乱させた場合: Clang で libc++ を使用すると、最初の ld 呼び出しから上記のエラーが発生します。私がそれを使用しない場合、2 番目の ld 呼び出しは問題なく実行され、アプリケーションは正常に実行されます。

私が libc++ を使用している理由は、C++11 の Threading を使用したいからです。これがないと、コンピュータにある GNU C++ 標準ライブラリから大量のエラーが発生します。エラーリストは膨大で、この問題とは関係がないため、投稿しません。

どうすれば SFML2 の問題を解決できるか、誰にも手掛かりがありますか? 必要がなければ、pthreads ライブラリを使用したくありません。

4

1 に答える 1

3

SFML2 ライブラリは、libc++ 以外のいくつかの C++ ライブラリに対してコンパイルされています (おそらく libstdc++?)。修正するには、SFML2 を -stdlib=libc++ で再コンパイルし、リンカーが SFML2 をアプリケーションにリンクするときに -stdlib=libc++ を認識していることを確認します。

sf::Window::createこれをデバッグするための鍵は、リンカーがstd::__1シンボルを探していることに注意することです。そして libc++ はstd::__1. しかし、他の std::libs はただstd. std::stringこれは、誤って 2 つの異なる std::lib を混在させて、リンク時エラーではなく実行時エラーが発生しないようにするための安全機能です。

于 2012-08-16T23:42:48.577 に答える