1

業界ではこの問題に関するベスト プラクティスが存在するはずだったので、ここで質問します。

この質問は、Linux で gcc を使用して、共有ライブラリ (.so) を実行可能ファイルにリンクすることに関するものです。しかし、Windows から始めましょう。

A.EXE 、 B.DLL 、 C1.DLL を開発しているとします。依存関係は

A -> B -> C1

つまり、A は B から API を呼び出し、B は C1 から API を呼び出すことによって自身を実装します。A は C1 の API を直接呼び出しません。

A.EXE (Visual C++ を使用) をリンクする場合、B.lib (インポート ライブラリ) を A のリンク コンポーネント (makefile 内) としてリストするだけで済みます。C1 は、A のメイクファイルに含まれている必要はありません。したがって、ある日、B をより適切に実装するために C1 を C2 に置き換えたいと考えています。C1 を置き換えたために、A の makefile を変更する必要はありません。

これは合理的な考え方に従っているため、素晴らしいことです。makefile は、それが直接関係するものだけを参照します。この便利さから、人々は Windows で LIB の代わりに DLL を書く傾向があります -- 私はそう思います。

ここで、Linux で gcc を使用します。同じ依存関係のシナリオでは、A のメイクファイルで、次のように C1 または C2 をリンク コンポーネントとして明示的にリストする必要があります。

gcc -o A a1.o a2.o -lB -lC1

非常に苛立たしいことに、10 個のプロジェクト A1、A2、... A10 が B を呼び出していると想像してください。C1 から C2 に移行するには、10 個のメイクファイルを変更する必要があります。

安堵する方法は？

4

2 に答える 2

3

いくつかの共有ライブラリlibfoo.soをリンクするとき、別の共有ライブラリとリンクできますlibbar.so:

  gcc -fPIC -g -Wall -c foo1.c
  gcc -fPIC -g -Wall -c foo2.c
  gcc -shared -o libfoo.so foo1.o foo2.o -lbar

を使用-lfooすると、libbar.so要求することなく自動的にリンクされます。

したがって、A の makefile で C1 または C2 を link-component として明示的にリストする必要はありません。

静的ライブラリしかない場合は、そうする必要がありますlib*.a

だからあなたはでプログラムを構築することができます

  gcc -Wall -g prog.c -lfoo

libbar.so単独で（明示的には言及していません）。

たとえばldd、GTK 共有ライブラリ (私の Debian システム上) で実行してみてください:

  ldd /usr/lib/x86_64-linux-gnu/libgtk-3.so.0

Windowsと Linuxの違いを理解するには、Levine のリンカーとローダーの本を読むことをお勧めします。彼らは異なる獣です。Program Library HowToもお読みください。.dll.so

GNU libtoolを使用したい (または使用しない) 場合があります。

ところで、依存関係を与えるpkg-configを使用することもできます...

于 2013-02-25T08:02:32.100 に答える
1

( )libBに依存していることを確認してください。のようなものでコンパイルされているはずです。libCldd libB.solibBgcc -o libB.so -shared -fPIC *.c -L/path/to/libC -lC -Wl,-rpath,/path/to/libC

を見つけたり、環境変数を使用したりするにはlibB.so、でコンパイルする必要があることに注意してください(上記のコマンドで が表示されてはなりません) 。-rpathlibC.soLD_LIBRARY_PATHlddlibC.so => not found

于 2013-02-25T08:13:27.543 に答える