☰

g++が/usr/*で既存のシステムヘッダ/ライブラリを接続/含めることを停止する方法は？

tag-icon • tag-icon gcc
g++が/usr/*で既存のシステムヘッダ/ライブラリを接続/含めることを停止する方法は？

一部のコードを実行するサーバーには、標準の場所（gmp、mpc、mpfr）に古いバージョンのgccがインストールされています。たとえば、管理者は更新をオフにしたいが、/usr*私のディレクトリ/home/usernameに最新バージョンのgccをインストールできます。私はこれを完了し、g++d46gcc 4.6.3が私のホームディレクトリにインストールされました/home/myusername/opt2/gcc-4.6.3。私もgmp、mpfr、mpcをインストールしました/home/myusername/tmp/gcc/{include,lib,share}。

輸出もしたし{LD_LIBRARY_PATH, LIBRARY_PATH,LD_RUN_PATH}=/home/myusername/tmp2/gcc/lib:/home/myusername/opt2/gcc-4.6.3/lib/gcc/x86_64-unknown-linux-gnu/4.6.3:/home/myusername/opt2/gcc-4.6.3/lib64:、PATH=/bin:/usr/bin:/home/myusername/opt2/gcc-4.6.3/bin:{C_INCLUDE_PATH,CPLUS_INCLUDE_PATH}=/home/myusername/tmp2/gcc/include:/home/myusername/opt2/gcc-4.6.3/include/c++/4.6.3:

次に、いくつかのテストコードをコンパイルします。

g++d46 -g -O3 -I/home/myusername/tmp2/gcc/include -L/home/myusername
/tmp2/gcc/lib -Wall testMPFR3.cpp -o myBin -lgmp -lgmpxx -lmpfr

うまくコンパイルされ実行されますが、実行した後ldd myBinはほとんどが私の正しいライブラリに関連付けられていることがわかりました。メインディレクトリ、まだ以下があります。

libm.so.6 => /lib64/libm.so.6 (0x0000003917e00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003917a00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003917600000)

-Iエクスポートされた環境変数と私とフラグが与えられたら、私のホームディレクトリにないものは何ですか？他の場所を見つけるかどうかはどうすればわかりますか-L？

g++ -Hまた、ヘッダーのソースを見ると、ほとんど（ありがたいことに新しいgmp、mpfrを含む）が私のホームディレクトリから来ていますが、いくつかは次のとおりです。

..... /usr/include/sys/cdefs.h
...... /usr/include/bits/wordsize.h
..... /usr/include/gnu/stubs.h
...... /usr/include/bits/wordsize.h
...... /usr/include/gnu/stubs-64.h
........ /usr/include/stdio.h
........ /usr/include/bits/wchar.h
........ /usr/include/xlocale.h
....... /usr/include/locale.h
 ..... /usr/include/ctype.h
....... /usr/include/bits/types.h
........ /usr/include/bits/wordsize.h
........ /usr/include/bits/typesizes.h
....... /usr/include/endian.h
........ /usr/include/bits/endian.h
........ /usr/include/pthread.h
......... /usr/include/sched.h
.......... /usr/include/time.h
.......... /usr/include/bits/sched.h
......... /usr/include/time.h
.......... /usr/include/bits/time.h
......... /usr/include/signal.h
.......... /usr/include/bits/sigset.h
......... /usr/include/bits/pthreadtypes.h
.......... /usr/include/bits/wordsize.h
......... /usr/include/bits/setjmp.h
.......... /usr/include/bits/wordsize.h

私のローカルgcc-4.6.3でこれが欠けている理由を理解できません。/usr/*リンカーは、ホームディレクトリでそのエントリが見つからない場合は、そのエントリに戻ることをどのように知ることができますか？

コンパイル時にそのフラグを使用することもできますが、何らかの--nostdinc理由で上記のヘッダーをローカルで見つけることができない問題が解決しない場合があります。

答え1

あなたが言及したヘッダーはglibcに/lib64/libc.so属しています/lib64/libm.so（その場所は/lib64すでにこれがコアシステムファイルであることを示しています（そうでない場合/usr/lib64）。）しかし、自分のコピーをそれにリンクすることができます。そうでなければ試すことは本当に重要です。デフォルトでは、すべてがlibcに関連付けられています。つまり、libに関連付けられたバイナリを取得しないように、すべてのもの（GCCとおそらくそれに依存するすべてを含む）を再コンパイルする必要があります。 -xyzとglibcのインストールとlib-xyzはシステムglibcを使用しているため、いくつかの不快な副作用がある可能性があります。

新しいツールチェーンを構築することに興味がある場合は確かにできますが、適切に実行するには次の点を見てください。最初からLinuxそして、ユースケースに適用される部分をはがしてください。

動的リンカーがどのように機能するかを確認してくださいman ld.so（前の質問で提案したように）。 GCCを含むヘッダーを検索する方法を理解するには、-Iおよび--sysrootについてお読みくださいman gcc。

関連情報