なぜg ++の問題にパラメータを渡す順序が遅いのですか

Question

最近、いくつかのライブラリを使用するアプリケーションを構築しようとしていましたが、共有オブジェクトファイルの形式で利用できます。私はCPPコードをコンパイルするのに多くの時間を無駄にしてしまい、うまくいきませんでした。以下は

は、以前、私はコード -

g++ -I/opt/ros/indigo/include/ -I/usr/include/eigen3/ -L/opt/ros/indigo/lib/ -lorocos-kdl -lkdl_parser test.cpp -o test 

上記のコマンドは、常に多くのundefined referencesエラーを示してコンパイルしようとしていた、コマンドです。好奇心のために、私はパラメータの順序を変更しました。以下は、私は完全なコードおよびソリューションhereを掲載working-

g++ -L/opt/ros/indigo/lib -I/opt/ros/indigo/include -I/usr/include/eigen3 test.cpp -lorocos-kdl -lkdl_parser -o test 

あるコマンドは、あります。

私の質問は、なぜg ++にパラメータを渡す順序が問題なのですか？将来このような問題を避けるための選択肢はありますか？

Answer 1

一般に、引数の順序は問題ありませんが、もちろん例外があります。たとえば、複数の-Oフラグを指定すると、最後に使用されるフラグになります。他のフラグにも同じフラグが使用されます。

ライブラリは少し異なりますが、そのためには順序が重要です。オブジェクトファイルまたはライブラリAがライブラリBに依存する場合、AはコマンドラインでBの前に来る必要があります。これは、リンカーがシンボルをスキャンする方法が原因です。ライブラリを使用すると、リンカは解決できるシンボルがあるかどうかをチェックします。このスキャンが終了すると、ライブラリは破棄され、再度検索されません。

あなたが持っているとき、これは、-lorocos-kdl -lkdl_parser test.cpporocos-kdlと最初​​は、これらのライブラリへの依存性がないことに気づくライブラリは、ライブラリからのシンボルは必要ありませんスキャンし、ソースによって生成されたオブジェクトファイルを継続するリンカファイル。

test.cpp -lorocos-kdl -lkdl_parserに注文を変更すると、リンカーはtest.cppで参照されている未定義のシンボルを解決することができます。

Answer 2

注文に気を配りたくない場合は、ライブラリの周りにかっこを使用することができます（少なくともgccのバージョンによっては）。

参照：具体的に

Why does the order in which libraries are linked sometimes cause errors in GCC?

：静的ライブラリが別のライブラリに依存しますが、他のライブラリ は再びかつてのライブラリに依存している場合

、サイクルがあります。 サイクリングに依存するライブラリを - （および - ）で囲むことで、 を - （-la -lb-）（これは - （および -）などの括弧をエスケープする必要があります）などで解決できます。リンカは、囲まれたlibを複数回検索して、サイクリングの依存関係を解決します。