私は C プログラミングの初心者です。.so ファイルについてはわかりません。それの必要性は何ですか?どうすれば作成できますか? 私のCコードまたはバイナリをそれにバインドする方法は? .so ファイルを作成せず、C コードの実行可能バイナリを直接作成する場合、その長所と短所は何ですか? その詳細な説明が必要です。
3 に答える
.so
ファイルは共有オブジェクトです。通常、共有ライブラリは として作成され.so
ます。
ライブラリを.so
u にすることで、メモリ使用の効率化を実現します。つまり、ライブラリを使用する複数のアプリケーションが実行されている場合、静的ライブラリの場合とは対照的に、ライブラリは一度だけメモリにロードされます。
動的ライブラリの作成:
gcc -Wall -fPIC -c *.c
gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0 *.o
-fPIC
: 位置に依存しないコードを出力するコンパイラ ディレクティブ。共有ライブラリに必要な特性です。
-shared
: 他のオブジェクトとリンクして実行可能ファイルを形成できる共有オブジェクトを生成します。
詳細については、こちらをご覧ください。
.so
共有オブジェクトの略です。Windows の世界では、これは DLL として知られています。
DLL を使用する場合とほぼ同じ方法で使用できます。アプリケーションを動的にリンクできます。
ライブラリの名前が libblah.so の場合、次のように gcc を使用してリンクできます。
gcc myprog.c -lblah -o myprog
共有ライブラリは、共通の機能を個別のファイルに分解するのに役立ちます。
ただし、共有ライブラリを使用すると、DLL Hellとして知られる現象が発生する可能性があります。この問題は Windows の世界で発生しましたが、使用されている共有ライブラリの正確なバージョンに細心の注意を払い、厳密なバージョン管理を実施しない限り、Linux システムでも同様に発生する可能性があります。たとえば、共有ライブラリ (作成したものではなく、システム共有ライブラリも含む) を使用してアプリケーションをコンパイルし、別の Linux ボックス (実質的に異なる Linux バージョンまたはディストリビューション) で同じ実行可能ファイルを実行しようとする場合が一般的です。 )、使用されている共有ライブラリが同じではないため、実行に失敗する可能性があります。
したがって、実行可能ファイルを再コンパイルせずに最大数の Linux システムに移植できるようにしたい場合は、静的にコンパイルするのが理にかなっています。これにより実行可能ファイルが大きくなりますが、一般的に DLL Hell に起因する問題が軽減されます。
他の回答に加えて、共有オブジェクト(または共有ライブラリ)を構築するには、関連するソースファイルを位置に依存しないコードモードでコンパイルする方がよいことに注意してください
gcc -Wall -O -fPIC src.c -c -o src.pic.o
-Wall
いくつかのソース コードをコンパイルするときに、すべての警告を要求することは常に役に立ちます。
*.pic.o
次に、これらすべてのファイルを.so
usingにリンクできます
gcc -shared src1.pic.o src2.pic.o -o shared.so
を使用して、共有ライブラリlibfoo.so
をその共有オブジェクトにリンクすることもできます
gcc -shared src1.pic.o src2.pic.o -lfoo -o shared.so
最後に、dlopenを使用して共有オブジェクトをプロセスに動的にロードできます。これはプラグインを入手するのに便利です。(そして、それらの規則を定義し、 を使用して重要なシンボルを取得しますdlsym
)
プログラム ライブラリのハウツーと実行可能ファイル & リンク形式&共有ライブラリウィキページも参照してください。
共有ライブラリを作成するときは、foo という名前を付けたほうがよいでしょう。ここで、lib
fooは任意の名前です。次に、リンク時に、 (実際にはリンカーに) toオプションを使用して、それを含むディレクトリについて通知し、foo オプションを使用してリンクします。たとえば、作成時にライブラリに名前を付け、(現在のディレクトリにある場合は)リンクする前に渡します。.so
-L
gcc
-l
libnewbie.so
-L.
-lnewbie
gcc -Wall myprog.c -L. -lnewbie -o myprog