1.-Iヘッダーファイルのパス
1.1単純なプロジェクト構造には-Iオプションは必要ありません
プロジェクト内のソースコードとヘッダーファイルの数が少ない場合、-Iオプションはまったく必要ありません。それらを同じレベルのディレクトリに配置すると、ソースファイルは通常どおりヘッダーファイルを見つけることができます。
//ttt.cpp
#include <stdio.h>
#include "data.h"
int main()
{
printf("Hello world\n");
printf("Data in header is %lf\n",pi);
}
// data.h
double pi=3.1415;
ターミナルに入力します。
gcc ttt.cpp
次に、通常どおりにコンパイルおよびリンクして、実行可能ファイルを作成できます。
1.2プロジェクトの構造はより複雑です
プロジェクトが進行するにつれて、より明確な構造にするために、多くの場合、ヘッダーファイル、ソースファイル、およびコンパイルされた結果を異なるフォルダーに分けます。デモンストレーションのために、ttt.cpp
とdata,h
を2つのフォルダーsrcとincludeにそれぞれ入れます。それでも(1.1)メソッドを使用すると、エラーが発生します。
junwuli@ubuntu:~/Desktop/gcctest/build$ gcc ../src/ttt.c
../src/ttt.c:2:10: fatal error: data.h: No such file or directory
#include "data.h"
^~~~~~~~
compilation terminated.
このとき、-Iオプションを使用する必要があります。
junwuli@ubuntu:~/Desktop/gcctest/build$ gcc ../src/ttt.c -I ../include/
junwuli@ubuntu:~/Desktop/gcctest/build$ ./a.out
Hello world
Data in header is 3.141500
メインプログラムが相対パスを書きたくないが、「。/include /」の代わりに簡潔な「head.h」だけを書きたいと仮定すると、このパラメーターを使用する必要があります。
gcc hello.c -Iinclude -o app
または
gcc hello.c -I include -o app
第二に、ライブラリの作成と使用
静的ライブラリであろうと動的ライブラリであろうと、ソースファイルをオブジェクトファイルにコンパイルしてから、オブジェクトファイルを統合してライブラリを形成する必要があります。ここのライブラリは実際のウェアハウスに似ていますが、保存されるコンテンツはターゲットファイルであり、ウェアハウスにあるものはヘッダーファイルによって異なります。
おそらくこれはプロセスです:
graph LR
源文件-->目标文件
目标文件-->库的打包
2.1ライブラリの命名規則
変数の命名と同様に、Linuxライブラリの命名もライブラリの属性と名前を明らかにします。
libxxx.so.x.y.z
libxxx.a.x.y.z
セクション | 意味 |
---|---|
lib |
ファイル属性 |
xxx |
ライブラリ名 |
.so /.a |
ライブラリタイプ |
.x.y.z |
バージョン番号[2] |
2.2静的ライブラリの作成と使用
2.2.1静的ライブラリの作成
ターゲットファイルを生成する例としてacbcを取り上げます。
gcc a.c b.c -c
同じ名前のターゲットファイルaoboがデフォルトで生成されます
前の手順で生成されたaoboマテリアルに従って、ターゲットファイルをパッケージ化します
ar rcs libtest.a a.o b.o
注:rcsは、ターゲットファイルを挿入してアーカイブファイルを作成し、インデックスを作成することを意味します。
2.2.2静的ライブラリを使用する
libtest.a +ヘッダーファイル、ヘッダーファイルとライブラリは静的ライブラリを使用します
gcc main.c -I ./include/ -L ./lib/ -ltest -o app
注:nm(name)はlibのコンテンツを表示できます
2.3ダイナミックライブラリの作成と使用
2.3.1ダイナミックライブラリの作成
ac bcを例にとると、-fPICオプションはターゲットファイルを生成します[3]:
gcc a.c b.c -c -fPIC(-fpic)
前の手順で生成されたaoboマテリアルによると、-sharedオプションを使用してターゲットファイルをパッケージ化します
gcc -shared a.o b.o -o libxxx.so
に
2.3.2ダイナミックライブラリを使用する
ヘッダーファイルとライブラリ設定はダイナミックライブラリを使用します
gcc main.c -I ./include/ -L ./lib/ -lxxx -o app
静的ライブラリと同様に、ライブラリのパスとライブラリの名前を指定します。ソースファイルと同じレベルのディレクトリにある場合は問題ありませんが、次のレベルのlibにある場合は、見つからないというプロンプトが表示されます。
ldd 用静态库编译的可执行文件
上記のものは、依存ライブラリとそれが見つかったかどうかを確認できます。
2.4ダイナミックライブラリ検索パス
ダイナミックライブラリ、実行可能プログラム、および.oファイルの形式はすべてELFであり、システムはld-linux.so.X [1]を使用して完了します。順番に、それらは次のとおりです。
- ELFファイルのDT_PRATHセクション
- 環境変数LD_LIBRARY_PATH
- ファイルリスト/etc/ld.so.cache
- / lib usr / libが
いずれかのステップで見つかった場合、通常の使用のためにメモリにロードされます。それ以外の場合は、ライブラリが見つからないというエラーが報告されます。
ノート:
[1] Glibcによってインストールされるライブラリの1つはld-linux.so.Xです。ここで、Xは数字であり、名前はプラットフォームによって異なります。たとえば、ubuntu18.04はld-linux-x86-64です。だから.2
[2]x
はメジャーバージョン番号を示し、異なるメジャーバージョンは一般的に互換性がありません。y
マイナーバージョン番号、ライブラリの増分アップグレード、元のインターフェイスは変更されませんが、いくつかの新しいインターフェイスが追加され、古いバージョンは同時に互換性があります。z
リリースバージョン番号、一部のライブラリ機能が間違っている、パフォーマンスが向上し、インターフェイスが増加または変更されない。
[3]さまざまなシステムと互換性を持たせるために、位置に依存しないコードを生成するときに-fPICパラメーターを使用する必要があります。
参考記事:
[1]「-fpicと-fPICの違い」作成者:zhang_dawei666(https://blog.csdn.net/xiangguiwang/article/details/81939237)
拡張:
動的ライブラリと静的ライブラリの違い:https://www.cnblogs.com/mhscn/p/4264357.html