2012-03-31 11 views
21

なぜいくつかの静的ライブラリ(lib * .a)は、共有ライブラリ(lib * .so)がリンクされているのと同じ方法でリンクできる(ld -l switch)いくつかできない?GCCを使用して静的ライブラリをリンクする適切な方法

静的かどうかにかかわらず、静的かどうかに関係なくすべてのライブラリが-l ...とリンクできることを教えていましたが、私はこれまでのライブラリ( "GLFW")を実行しましたが、この方法でリンクしようとするとリンクエラーが発生します。

this questionの回答によると、静的ライブラリをリンクする「適切な」方法は、-lを使用するのではなく、自分のオブジェクトファイルとともに直接それらを含めることです。そして、GLFWライブラリの場合、これは確かに問題を解決します。しかし、私が使用している他のすべての静的ライブラリは、-lとリンクするとうまく動作します。だから、

  • ではなく、直接含まよりリンクされたときに動作しないように、この1つのライブラリを引き起こす可能性がありますか?私が原因を知っていれば、ライブラリを編集して再コンパイルして問題を解決できるかもしれません。
  • 共有ライブラリをリンクするのと同じ方法で静的ライブラリをリンクすることを想定していないのは本当ですか? (そうでない場合は、なぜですか?)
  • ライブラリがこのように直接組み込まれている場合、リンカは未使用のライブラリ関数を出力実行可能ファイルから削除できますか?

答えて

25

返信いただきありがとうございます!問題はリンク順序に起因することが判明しました。どうやら、他のライブラリの依存関係を持っているライブラリを使用している場合、他の依存関係はの後ではなく、のリストになければなりません。新しいものを学びました!

5

ライブラリのパスを-Lを使用してGCCに伝えたことがありますか? -lを単独で使うことで、GCCは標準ディレクトリで利用できるライブラリのみをリンクすることができます。

-L[path] -l[lib] 
+0

はい、各ライブラリへのパスは、対応する-lフラグの前に-Lを使用して提供されます。 GCCはライブラリを見つけることができますが、ライブラリ内から多数の未定義参照エラーを出します。 – Nairou

1

理由は歴史的です。 "ar"ツールは元のPDP11 unixのファイルアーカイブツールでしたが、後でその目的のために "tar"で完全に置き換えられました。ファイル(この場合はオブジェクトファイル)をパッケージに格納します。また、リンカーが使用するシンボルテーブルを含む別の拡張があります。アーカイブ内のファイルを手動で管理していて、シンボルテーブルが期限切れになる可能性があります。

簡単な答えは、任意のアーカイブで "ranlib"ツールを使用してシンボルテーブルを再作成できることです。それを試してください。より広義には、破損したライブラリがどこから来ているのか把握し、修正してください。

+2

私は、OPはライブラリとリンクする*ことを意味し、ライブラリを作成しないと思います。 – ams

5

静的ライブラリをリンクする正しい方法は、-lを使用することですが、ライブラリが検索パス上に見つかった場合にのみ動作します。そうでなければ、-Lを使ってリストにディレクトリを追加するか、名前でファイルに名前を付けることができます。

共有ライブラリについても同じことが言えますが、おそらく実際に見つかる可能性は高いですが。

関連する問題