サードパーティ製ライブラリとヘッダファイルをgcc、g++に追加する方法
6179 ワード
サードパーティ製ライブラリを参照した後、使用時に-Lの後にパスを追加してサードパーティ製ライブラリのパスを指定し、-Iの後にパスを追加してヘッダファイルのパスを指定することができます.パスを追加する方法もあります
gcc、g++のコンパイルパスでは、-Lと-Iを追加しなくても使用できます.方法は次のとおりです.
1、/etc/ld.so.confファイルにカスタムlibライブラリのパスを追加し、/sbin/ldconfigを実行します.この方法はすべての端末に有効です.
2、LD_LIBRARY_PAHTにパスを追加:export LD_LIBRARY_PATH=あなたのライブラリパス:$LD_LIBRARY_PATH,この方法は端末の再起動後に失効した
3、/etc/profileに入れる
export C_INCLUDE_PATH=C_INCLUDE_PATH:ヘッダファイルパス
export CPLUS_INCLUDE_PATH=CPLUS_INCLUDE_PATH:ヘッダファイルパスは保存可能です.
Linuxアプリケーションのデバッグ-debug coredump作成者:Linuxシステムでは、アプリケーションの実行中にプログラムが突然クラッシュすることがよくあります.ヒント:Segmentation fault.これは、アプリケーションがSIGSEGV信号を受信したためです.この信号は、プロセスに無効なストレージアクセスが発生した場合、この信号を受信すると、デフォルトの動作はw/coreを終了することであることを示す.終了w/coreは、プロセスの現在のディレクトリでcoreファイルを生成し、プロセスのメモリイメージをcoreファイルにコピーすることを意味します.coreファイルのデフォルト名は「core」である(これはUnix系システムの昔からの機能である).実際にはSIGSEGV信号のみがcoredumpを生成するわけではなく、以下の信号もcoredumpを生成する:SIGABRT(異常終了)、SIGBUS(ハードウェア障害)、SIGEMT(ハードウェア障害)、SIGFPE(算術異常)、SIGILL(不正なハードウェア命令)、SIGIOT(ハードウェア障害)、SIGQUIT、SIGSYS(無効なシステム呼び出し)、SIGTRAP(ハードウェア障害)など.プログラムの開発デバッグ段階で(特に大規模なソフトウェア開発)、プログラムの異常なクラッシュが発生した場合、従来のデバッグ方法は常に苦痛である.無限のlogにも意味のある情報があるとは限らない.GDBがcoreファイルを利用してデバッグする方法を提供し、利用することで、このような問題のデバッグを大幅に便利にすることができる.以下、簡単な例を通じて、GDBを通じてどのようにデバッグするかを見てみよう.個の不正アクセスメモリによるプログラムのクラッシュ.ここでは、ダイナミックライブラリのデバッグについて説明します./****************mylib.h **********/#ifndef __MY_LIB_H__ #define __MY_LIB_H__ int add(int x, int y); #endif//__MY_LIB_H__/******** end **********//******** mylib.c **********/#include #include "mylib.h"int add(int x, int y) { char* pc = NULL; *pc = 10; return x + y; }/******** end **********//******** main.c **********/#include #include #include "mylib.h"int main (void) { int ret = -1; int a = 10, b = 20; ret = add(a, b); printf("The result is: %d", ret); return 0; }/******** end **********/##################################### # File Name: Makefile # ##################################### CC = gcc LD = gcc all: $(CC) mylib.c -g -I. -fPIC -shared -o libmylib.so $(CC) main.c -g -I. -L. -lmylib -o test clean: rm *.so test#######################################################################################h、mylib.c、main.c、Makefile. 1)テストコードをコンパイルする.注)コンパイル時の-gオプションは必須です.[xxx@yyy]$ make gcc mylib.c -g -I. -fPIC -shared -o libmylib.so gcc main.c-g-I.-L.-lmylib-o t lsコマンドでテストプログラムtestが生成されたことがわかります.[xxx@yyy]$ ls libmylib.so main.c Makefile mylib.c mylib.h test
2)試験手順の実行[xxx@yyy]$ ./test ./test: error while loading shared libraries: libmylib.so:cannot open shared object file:No such file or directoryこのエラーは、プログラムが実行中に対応するダイナミックライブラリファイルが見つからないことを示しています.この場合、環境変数LD_を通過する必要があります.LIBRARY_PATHは、ランタイム・ダイナミック・ライブラリの検索ディレクトリを指定します.現在のディレクトリには、次のようなダイナミック・ライブラリがあります.[xxx@yyy]$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. 3)試験手順の再実行[leo@localhost debug]$ ./test Segmentation fault [leo@localhost debug]$ ls libmylib.so main.c Makefile mylib.c mylib.h test 4)coreファイルサイズSegmentation faultを予定通りに設定しますが、私たちがもっと見たいcoreファイルはありません!従来、システムはデフォルトでcoreファイルのサイズを0に設定しており、言い換えればcoreファイルは生成されません.ulimitコマンドでcoreファイルのサイズを変更できます.unlimitedはcoreファイルのサイズを制限しないことを示します.次のようにします(coreファイルのサイズを設定するにはroot権限が必要です).root@yyy]# ulimit -c unlimited [root@yyy]# ./test Segmentation fault (core dumped) [root@yyy]# ls core.2890 libmylib.so main.c Makefile mylib.c mylib.h test 5)coreファイルのフォーマットを設定し、出力パスは次のコマンドでcoreファイルの名前付きフォーマット、パスなどを指定できます(root権限が必要です):[root@yyy]# echo "core_%e_%s">/proc/sys/kernel/core_pattern [root@yyy]# ./test Segmentation fault (core dumped) [root@yyy]# ls core.2890 core_test_11.2898 libmylib.so main.c Makefile mylib.c mylib.h test 6)デバッグ[root@yyy]# gdb test core.2890 GNU gdb Red Hat Linux (6.5-8.fc6rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying"to see the conditions. There is absolutely no warranty for GDB. Type "show warranty"for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `./test'. Program terminated with signal 11, Segmentation fault. Error while mapping shared library sections: libmylib.so: Success. Reading symbols from/home/xxx/tst/libmylib.so...done. Loaded symbols for libmylib.so Reading symbols from/lib/i686/libc.so.6...done. Loaded symbols for/lib/i686/libc.so.6 Reading symbols from/lib/ld-linux.so.2...done. Loaded symbols for/lib/ld-linux.so.2 #0 0x00a8969c in ?? ()(gdb)GDBコマンドwhere(gdb)where#0 0 x 001 ec 44 c in?() #1 0x00000000 in ?? () ?? ()私たちが見たいわけではありません.なぜなら、GDBが私たちが書いたダイナミックライブラリlibmylibを正しくロードできないからです.so,ここでGDBの動的ライブラリ探索経路を設定する必要がある:(gdb)set solib-search-path.Reading symbols from/home/xxx/test/tst/libmylib.so...done. Loaded symbols for/home/xxx/test/tst/libmylib.so Reading symbols from/lib/i686/libc.so.6...done. Loaded symbols for/lib/i686/libc.so.6 Reading symbols from/lib/ld-linux.so.2...done. Loaded symbols for/lib/ld-linux.so.2 GDBにlibmylibがロードされていることがわかります.so,whereコマンドを再入力:(gdb)where#0 0 0 x 001 ec 44 c in add(x=10,y=20)at mylib.c:8 #1 0x0804847c in main () at main.c:12(gdb)今回期待していた結果が現れ、GDBはエラーが発生した位置:mylibを明確にリストした.cの8行目、よし、そこへcodeを直しに行こう
gcc、g++のコンパイルパスでは、-Lと-Iを追加しなくても使用できます.方法は次のとおりです.
1、/etc/ld.so.confファイルにカスタムlibライブラリのパスを追加し、/sbin/ldconfigを実行します.この方法はすべての端末に有効です.
2、LD_LIBRARY_PAHTにパスを追加:export LD_LIBRARY_PATH=あなたのライブラリパス:$LD_LIBRARY_PATH,この方法は端末の再起動後に失効した
3、/etc/profileに入れる
export C_INCLUDE_PATH=C_INCLUDE_PATH:ヘッダファイルパス
export CPLUS_INCLUDE_PATH=CPLUS_INCLUDE_PATH:ヘッダファイルパスは保存可能です.
01 1125 wget http://oss.metaparadigm.com/json-c/json-c-0.9. tar .gz 02 1128 tar zxvf json-c-0.9. tar .gz 03 1130 cd json-c-0.9 04 1141 ./configure 05 1142 make 06 1143 make install 07 1174 echo "/usr/local/lib/" >/etc/ld.so.conf.d/json-c-0.9.conf 08 175 /sbin/ldconfig 09 1176 gcc json.c -I /usr/ local /include/json/ -ljson 10 1177 ./a.out Linuxアプリケーションのデバッグ-debug coredump作成者:Linuxシステムでは、アプリケーションの実行中にプログラムが突然クラッシュすることがよくあります.ヒント:Segmentation fault.これは、アプリケーションがSIGSEGV信号を受信したためです.この信号は、プロセスに無効なストレージアクセスが発生した場合、この信号を受信すると、デフォルトの動作はw/coreを終了することであることを示す.終了w/coreは、プロセスの現在のディレクトリでcoreファイルを生成し、プロセスのメモリイメージをcoreファイルにコピーすることを意味します.coreファイルのデフォルト名は「core」である(これはUnix系システムの昔からの機能である).実際にはSIGSEGV信号のみがcoredumpを生成するわけではなく、以下の信号もcoredumpを生成する:SIGABRT(異常終了)、SIGBUS(ハードウェア障害)、SIGEMT(ハードウェア障害)、SIGFPE(算術異常)、SIGILL(不正なハードウェア命令)、SIGIOT(ハードウェア障害)、SIGQUIT、SIGSYS(無効なシステム呼び出し)、SIGTRAP(ハードウェア障害)など.プログラムの開発デバッグ段階で(特に大規模なソフトウェア開発)、プログラムの異常なクラッシュが発生した場合、従来のデバッグ方法は常に苦痛である.無限のlogにも意味のある情報があるとは限らない.GDBがcoreファイルを利用してデバッグする方法を提供し、利用することで、このような問題のデバッグを大幅に便利にすることができる.以下、簡単な例を通じて、GDBを通じてどのようにデバッグするかを見てみよう.個の不正アクセスメモリによるプログラムのクラッシュ.ここでは、ダイナミックライブラリのデバッグについて説明します./****************mylib.h **********/#ifndef __MY_LIB_H__ #define __MY_LIB_H__ int add(int x, int y); #endif//__MY_LIB_H__/******** end **********//******** mylib.c **********/#include #include "mylib.h"int add(int x, int y) { char* pc = NULL; *pc = 10; return x + y; }/******** end **********//******** main.c **********/#include #include #include "mylib.h"int main (void) { int ret = -1; int a = 10, b = 20; ret = add(a, b); printf("The result is: %d", ret); return 0; }/******** end **********/##################################### # File Name: Makefile # ##################################### CC = gcc LD = gcc all: $(CC) mylib.c -g -I. -fPIC -shared -o libmylib.so $(CC) main.c -g -I. -L. -lmylib -o test clean: rm *.so test#######################################################################################h、mylib.c、main.c、Makefile. 1)テストコードをコンパイルする.注)コンパイル時の-gオプションは必須です.[xxx@yyy]$ make gcc mylib.c -g -I. -fPIC -shared -o libmylib.so gcc main.c-g-I.-L.-lmylib-o t lsコマンドでテストプログラムtestが生成されたことがわかります.[xxx@yyy]$ ls libmylib.so main.c Makefile mylib.c mylib.h test
2)試験手順の実行[xxx@yyy]$ ./test ./test: error while loading shared libraries: libmylib.so:cannot open shared object file:No such file or directoryこのエラーは、プログラムが実行中に対応するダイナミックライブラリファイルが見つからないことを示しています.この場合、環境変数LD_を通過する必要があります.LIBRARY_PATHは、ランタイム・ダイナミック・ライブラリの検索ディレクトリを指定します.現在のディレクトリには、次のようなダイナミック・ライブラリがあります.[xxx@yyy]$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. 3)試験手順の再実行[leo@localhost debug]$ ./test Segmentation fault [leo@localhost debug]$ ls libmylib.so main.c Makefile mylib.c mylib.h test 4)coreファイルサイズSegmentation faultを予定通りに設定しますが、私たちがもっと見たいcoreファイルはありません!従来、システムはデフォルトでcoreファイルのサイズを0に設定しており、言い換えればcoreファイルは生成されません.ulimitコマンドでcoreファイルのサイズを変更できます.unlimitedはcoreファイルのサイズを制限しないことを示します.次のようにします(coreファイルのサイズを設定するにはroot権限が必要です).root@yyy]# ulimit -c unlimited [root@yyy]# ./test Segmentation fault (core dumped) [root@yyy]# ls core.2890 libmylib.so main.c Makefile mylib.c mylib.h test 5)coreファイルのフォーマットを設定し、出力パスは次のコマンドでcoreファイルの名前付きフォーマット、パスなどを指定できます(root権限が必要です):[root@yyy]# echo "core_%e_%s">/proc/sys/kernel/core_pattern [root@yyy]# ./test Segmentation fault (core dumped) [root@yyy]# ls core.2890 core_test_11.2898 libmylib.so main.c Makefile mylib.c mylib.h test 6)デバッグ[root@yyy]# gdb test core.2890 GNU gdb Red Hat Linux (6.5-8.fc6rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying"to see the conditions. There is absolutely no warranty for GDB. Type "show warranty"for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `./test'. Program terminated with signal 11, Segmentation fault. Error while mapping shared library sections: libmylib.so: Success. Reading symbols from/home/xxx/tst/libmylib.so...done. Loaded symbols for libmylib.so Reading symbols from/lib/i686/libc.so.6...done. Loaded symbols for/lib/i686/libc.so.6 Reading symbols from/lib/ld-linux.so.2...done. Loaded symbols for/lib/ld-linux.so.2 #0 0x00a8969c in ?? ()(gdb)GDBコマンドwhere(gdb)where#0 0 x 001 ec 44 c in?() #1 0x00000000 in ?? () ?? ()私たちが見たいわけではありません.なぜなら、GDBが私たちが書いたダイナミックライブラリlibmylibを正しくロードできないからです.so,ここでGDBの動的ライブラリ探索経路を設定する必要がある:(gdb)set solib-search-path.Reading symbols from/home/xxx/test/tst/libmylib.so...done. Loaded symbols for/home/xxx/test/tst/libmylib.so Reading symbols from/lib/i686/libc.so.6...done. Loaded symbols for/lib/i686/libc.so.6 Reading symbols from/lib/ld-linux.so.2...done. Loaded symbols for/lib/ld-linux.so.2 GDBにlibmylibがロードされていることがわかります.so,whereコマンドを再入力:(gdb)where#0 0 0 x 001 ec 44 c in add(x=10,y=20)at mylib.c:8 #1 0x0804847c in main () at main.c:12(gdb)今回期待していた結果が現れ、GDBはエラーが発生した位置:mylibを明確にリストした.cの8行目、よし、そこへcodeを直しに行こう