【最大10000ポイント】当たる!!質問投稿キャンペーン!

(1)gccは、オプションを指定しないで、/usr/include以外のヘッダーファイルを見に行きますか?

(2)/usr/includeの中はディストリビューションによって異なりますか?

(3)/usr/includeはアプリケーションなどをインストールしたりして、増えたりするものなんでしょうか?

このQ&Aに関連する最新のQ&A

A 回答 (2件)

gccと言ってもデフォルトは初期設定や環境によって異なるので、OSのプリインストールされている構成を前提に回答します。



> (1)gccは、オプションを指定しないで、/usr/include以外のヘッダーファイルを見に行きますか?

どこを見に行くかは、gcc/cppdefault.c いうファイルで定義されています。
関係ありそうなのは、

LOCAL_INCLUDE_DIR: /usr/local/include
PREFIX_INCLUDE_DIR: $(prefix)/include
GCC_INCLUDE_DIR: $(libdir)/gcc/$(target_noncanonical)/$(version)/include
TOOL_INCLUDE_DIR: $(prefix)/$(target_noncanonical)/include
STANDARD_INCLUDE_DIR: /usr/include

/usr/include以外ということですので、以下の3つが該当します。

/usr/local/include
/usr/lib/gcc/$(target_noncanonical)/$(version)/include
/usr/$(target_noncanonical)/include

target_noncanonicalとは、「x86_64-redhat-linux」などのような文字列です。
versionは例えば4.1.2 であれば、「4.1.2」です。

> (2)/usr/includeの中はディストリビューションによって異なりますか?

異なります。ただし、普通は glibc が要なので、コア部分はほとんど違わないでしょうが。

> (3)/usr/includeはアプリケーションなどをインストールしたりして、増えたりするものなんでしょうか?

rpm はdeb の開発用のパッケージ(rpm であれば「-devel」と付いているやつです)をインストールすれば増えます。

この回答への補足

わかりやすい説明ありがとうございます。

質問の内容は理解できました。
ありがとうございます。

1つ疑問なんですが、

> (2)/usr/includeの中はディストリビューションによって異なりま>すか?

>異なります。ただし、普通は glibc が要なので、コア部分はほとん>ど違わないでしょうが。

とありますが、僕の知識不足で理解することができませんでした。

includeファイルとglibcとはどうゆう関係なんでしょうか?

すいませんが知っていましたら、ご教授お願いします。

補足日時:2012/06/15 17:51
    • good
    • 0

> (1)gccは、オプションを指定しないで、/usr/include以外のヘッダーファイルを見に行きますか?



とりあえずカレントディレクトリは参照するはずです。

ただし、#include "file" と #include <file> では、違うかも知れません

> (2)/usr/includeの中はディストリビューションによって異なりますか?

異なる可能性が高いと思います。
ディストリビューションのバージョンによっても異なるかと

> (3)/usr/includeはアプリケーションなどをインストールしたりして、増えたりするものなんでしょうか?

フルパッケージのインストールを強要しないディストリビューションでは、追加されることもあるでしょう。
    • good
    • 0

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aと関連する良く見られている質問

QLinuxのgccのインクルードパス?

Linuxのgccで、インクルードファイルやライブラリのパスを設定する方法が知りたいのですが、gccについて詳しい書籍やサイトがありましたら、教えてください。

gccとccの違いも知りたいです。

例)
#include "example.h"

このままだと、example.hが無いと表示されます。

Aベストアンサー

標準ライブラリのパスは、gccのインストール時に指定して、Cプリプロセッサの中に組み込まれます。

#include "example.h"
は、まずカレントディレクトリを探し、次に gccコマンドラインの -I オプションで指定したディレクトリを探し、最後に標準ライブラリが探されます。

#include <example.h>
は、カレントディレクトリを探さない点が異なります。

ccも基本的には同じですが、Unixの種類によって機能が異なる可能性があります。Linuxの場合はcc=gccです。

Qfgetsなどのときのstdinのバッファを消すには?

こんにちは,今C(C++でない)を使用しています。
たとえば,
char str[20]
fgets(str,sizeof(str),stdin)
としたときに20字以上を打つと,stdinのバッファに20字以上の分が残ったままになります。

C++などでは
fflush(stdin)で,うまくいきますが,普通のCでは対応がされていないみたいでうまくいきません。

よろしくお願いします。

Aベストアンサー

あ,テキスト入力だからこんな大掛かりなことしなくてもいいんだ.
末尾に'\n'が出るまで掃出せばいいんですよね.

fgets(str, sizeof(str), stdin);
if ( str[strlen(str)-1] != '\n' ){
while( getchar() != '\n' );
}

でいいんだ.失礼しました.

Qセグメンテーション違反

C言語を使用しています。

構造体に値をいれようとしたら、コンパイルは出来るのですが、実行時に
「セグメンテーション違反です (core dumped)」
となってしまい、それ以上行えません。

構造体と代入したい変数との型は、合っています。

いろいろ本などで見ましたが、何が原因かわからず困っています。
教えてください。
宜しくお願いします。

Aベストアンサー

OSは何でしょうか。コンパイラは何を使用していますか?
通常、デバッグオプションをつけて実行すると、異常の発生したソースの箇所で止まりますので、それが手がかりになります。またNo1の方が言われてますように、ソースが公開できるのであれば、ソースを提示するのが良いかと思います。

Q構造体の初期化のmemsetの第三引数

memset(&lvitem, 0, sizeof(LVITEM));
memset(&lvitem, 0, sizeof(lvitem));
LVITEMに特化した質問ではなく構造体の初期化について、この2つの書き方によるソース管理やコンパイルでのメリットとデメリットを教えてください。

Aベストアンサー

(1)memset(&lvitem, 0, sizeof(LVITEM));
この書き方は、構造体LVITEMを初期化しているんだな、と分かりやすい。
(2)memset(&lvitem, 0, sizeof(lvitem));
この書き方はとにかく変数lvitemを初期化するんだな、という感じだが、型が分からないので宣言しているところを参照しなければならない。
それともう一つ、ただ単に何回も初期化するんでなければ、こういう書き方もできる。
(3)LVITEM lvitem = {0};

結局どれがいいのかといえば、個人的にはケースバイケースですねえ。初期化を1回すればいいような感じなら(3)、構造体名を明示した方が調べる手間がなくなるようなら(1)、そうでなければ(2)を使います。
コンパイルでのメリット、デメリットは特にないんじゃないかなあ。アセンブラがまだ全盛だった頃ならともかく、いまじゃどのコンパイラだって最適化オプションで同じようなコードはくでしょう。
気にするほどでもないと思うけど…

Qdlopenで目的の*.soファイルをロードできません

以下C++のテストソース2ファイルをコンパイルし実行したのですが、libtest.soをロードすることが出来ません。OSはRed Hat Linux EL4.0WS、カーネルは2.6.9-5です。原因と思しき点がお分かりの方がいれば、教えて頂けますでしょうか。

********** ソースファイル1(libtest.cpp) **********
#include <stdio.h>
#include <stdlib.h>

extern "C" {void printTest();}

void printTest(){
printf(" *** SUCCESS!! *** Java - Native Interface test at INOAC\n");
}

********** ソースファイル2(test.cpp) **********
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
static void (*testFunc)();

int main(){
void *library;
const char * error;

library = dlopen("libtest.so",RTLD_LAZY);
if(library==NULL){
printf("Could not open libtest.so\n");
exit(1);
}
dlerror();

testFunc = (void (*)())dlsym(library,"printTest");
error = dlerror();
if(error){
printf("Could not find the function printTest\n");
exit(1);
}

printf("Test from C;\n");
(*testFunc)();
dlclose(library);
return 0;
}

********** 実行方法 **********
pgCC -fPIC -shared libtest.cpp -o libtest.so
pgCC -ldl test.cpp -o test.exe
setenv LD_LIBRARY_PATH "."
./test.exe

以下C++のテストソース2ファイルをコンパイルし実行したのですが、libtest.soをロードすることが出来ません。OSはRed Hat Linux EL4.0WS、カーネルは2.6.9-5です。原因と思しき点がお分かりの方がいれば、教えて頂けますでしょうか。

********** ソースファイル1(libtest.cpp) **********
#include <stdio.h>
#include <stdlib.h>

extern "C" {void printTest();}

void printTest(){
printf(" *** SUCCESS!! *** Java - Native Interface test at INOAC\n");
}

********** ソースファイル2(tes...続きを読む

Aベストアンサー

dlerror() の使い方を間違えていませんか?

library = dlopen("libtest.so",RTLD_LAZY);
if(library==NULL){
printf("Could not open libtest.so?n");
printf("dlerror: %s?n", dlerror() );
exit(1);

とかするとなんと言ってくるでしょう?

Qシェルスクリプトの実行、「source」と「.」の違いについて

bashのシェルスクリプトを書いています。
当方、Mac Snow Leopard を使っているため、seq コマンドがデフォルトでは使えません。
そこで、.bashrc 内に、seq 関数をあらかじめ自分で定義して、他で使い回したいと思っています。
.bashrc の中に、
function seq() {
i=$1
while [ $i -le $2 ] ; do
echo $i
let i=$i+1
done
}
と、関数を定義しました。
seq 関数をターミナル上で実行すると、
>seq 0 2
0
1
2
と正しく、表示されます。次に、

#!/bin/sh
seq 0 2

と記述したシェルスクリプト(temp.sh)を「source」で実行すると、
>source temp.sh
0
1
2
と正しく、表示されますが、「.」で実行すると、
>./temp.sh
./temp.sh: line 2: seq: command not found
と言われます。
どのような理由によってこの違いが出るのでしょうか??

bashのシェルスクリプトを書いています。
当方、Mac Snow Leopard を使っているため、seq コマンドがデフォルトでは使えません。
そこで、.bashrc 内に、seq 関数をあらかじめ自分で定義して、他で使い回したいと思っています。
.bashrc の中に、
function seq() {
i=$1
while [ $i -le $2 ] ; do
echo $i
let i=$i+1
done
}
と、関数を定義しました。
seq 関数をターミナル上で実行すると、
>seq 0 2
0
1
2
と正しく、表示されます。次に、

#!/bin/sh
seq 0 2

...続きを読む

Aベストアンサー

追記

source は現在のシェルで実行し、結果がそのまま現在のシェルに適応されます。
今回の temp.sh なら
> source temp.sh

> seq 0 2
と入力したのと同等ということになります。

> ./temp.sh
この . はコマンドではなく、 temp.shへのパスを指定するものです。
実行ファイル名だけでコマンドとして実行できるのは、環境変数PATHで指定したディレクトリにあるものだけです。それ以外は、その実行ファイルへの絶対パス、または相対パスが必要となります。
これは、カレントディレクトリにある実行ファイルも例外ではありません。
環境変数PATHに . が無い場合は、 ./ファイル名 と相対パスを指定する必要があります。
(この点は、常に . がPATHにあるように振る舞うMS-DOSやコマンドプロンプトとは違います)
逆に、PATH上にあれば(例えば、 PATH=$HOME/bin:(以下略)となっている時の $HOME/bin )、 temp.sh とファイル名だけで実行できます。

また、こうしたコマンドは新規プロセスで実行されますので、環境変数を除いて、現在の設定は継承されません。
対話的ではないbashや、 shとして起動された bash は .bashrcを読まないので、そこに書いてあることは無効となります。

追記

source は現在のシェルで実行し、結果がそのまま現在のシェルに適応されます。
今回の temp.sh なら
> source temp.sh

> seq 0 2
と入力したのと同等ということになります。

> ./temp.sh
この . はコマンドではなく、 temp.shへのパスを指定するものです。
実行ファイル名だけでコマンドとして実行できるのは、環境変数PATHで指定したディレクトリにあるものだけです。それ以外は、その実行ファイルへの絶対パス、または相対パスが必要となります。
これは、カレントディレクトリにある実行...続きを読む

Qfgetsで拾われる改行文字を削除したい

お世話になります

 C言語初心者のものです。今課題でC言語を用いたプログラミングを
Fedora上でやっています。問題は、fgetsでテキストファイルから、取得
した文字列の中から改行文字を削除できないことです。文字変数のアド
レスはわかっているのですが、終端文字に置換しようとすると、セグメ
ントエラーになってしまいます。これは如何にして解決すべきでしょう
か。よろしくお願いします。

Aベストアンサー

ポインタとかアドレスとか、C言語の用語としてあるものを別の意味に使うとまぎらわしいです。

「ポインタ」「アドレス」と言われたら、 この例なら str, str+i が思い浮びます。
「文字変数のアドレス」だと
char c ;
に対しての
&c
が思い浮びます。

配列なら「添字」、意味的には「x文字目」ですね。

> for(i=0;;i++){
> if(*(str+i)=='/n') {
> *(str+i)='\0';
> break;
> }
> }
/nが\nの間違いなら、この方法で半分正解です。もう少し広い範囲(可能なら全体)で見ないことにはなんとも言えません。
fgetsが最大文字数に達したり、ファイルの最後になったりで、strに改行文字が含まれない場合には、このループは止まりません(Segmentension Falutになって止まる)

・そのような状態になってないか、予めチェックする
・ループを終了させる仕組みを用意しておく
: forの終了条件を記述する、for中で if(*(str+i)=='\0') { break;} 等としておく、等
といった対策が必要です。


あと細かいところを言えば
・strを配列で用意したなら *(s+i)じゃなくてs[i]でいいんじゃないかな
・あるいは char *pみたいにしておいて、 iのループでなく pでループを組む( for(p=str;*p!='\0';p++) )とか。

ポインタとかアドレスとか、C言語の用語としてあるものを別の意味に使うとまぎらわしいです。

「ポインタ」「アドレス」と言われたら、 この例なら str, str+i が思い浮びます。
「文字変数のアドレス」だと
char c ;
に対しての
&c
が思い浮びます。

配列なら「添字」、意味的には「x文字目」ですね。

> for(i=0;;i++){
> if(*(str+i)=='/n') {
> *(str+i)='\0';
> break;
> }
> }
/nが\nの間違いなら、この方法で半分正解です。もう少し広い範囲(可能なら全体)で見ないことにはなんとも言えません。
fgetsが...続きを読む

QPATHとLD_LIBRARY_PATHの設定

solarisまたはlinuxで、ソースインストールする際のPATHとLD_LIBRARY_PATHについての質問です。

1.
ソースインストールする際に、事前にPATHやLD_LIBRARY_PATHを設定してから、
./configure → make をするよう説明しているサイトがありますが、
インストールするときだけPATHやLD_LIBRARY_PATHを変更しても問題ないのでしょうか?

たとえば、インストール時に$ export LD_LIBRARY_PATH=/lib:/usr/libとしてインストールしたけど、
実際にサービスを起動する際はLD_LIBRARY_PATHは未設定というような状態のことです。


2.
ソースインストールする際、./configureとmakeを実行する一般ユーザのPATHやLD_LIBRARY_PATHの示すパスと、
make installを実行するrootユーザのPATHやLD_LIBRARY_PATHの示すパス(または順番)が異なっていても大丈夫でしょうか?

たとえば、一般ユーザはLD_LIBRARY_PATH=/lib:/usr/libだけど、
rootユーザはLD_LIBRARY_PATH=/usr/local/lib:/lib というような状態のことです。


3.
exportなどによる一時的な設定ではなく、profieや/etc/ld.so.conf(solarisではcrleによる)などで
固定で設定する場合、注意することはありますか?
個人的に思っているのは、パスの先頭に追加すると既存サービスなどに影響を与える可能性があるので、
最後尾に追加していくことぐらいです。


以上です。よろしくお願いします。

solarisまたはlinuxで、ソースインストールする際のPATHとLD_LIBRARY_PATHについての質問です。

1.
ソースインストールする際に、事前にPATHやLD_LIBRARY_PATHを設定してから、
./configure → make をするよう説明しているサイトがありますが、
インストールするときだけPATHやLD_LIBRARY_PATHを変更しても問題ないのでしょうか?

たとえば、インストール時に$ export LD_LIBRARY_PATH=/lib:/usr/libとしてインストールしたけど、
実際にサービスを起動する際はLD_LIBRARY_PATHは未設定というような状態のこと...続きを読む

Aベストアンサー

> ソースインストールする際に、事前にPATHやLD_LIBRARY_PATHを設定してから、
> ./configure → make をするよう説明しているサイトがありますが、
> インストールするときだけPATHやLD_LIBRARY_PATHを変更しても問題ないのでしょうか?

インストールアプリによります。

/libまたは/usr/lib以外の場所にインストールされたライブラリとリンクされた場合、
基本的には実行するときもLD_LIBRARY_PATHの設定が必要になります。

ただし、インストール時に実行時パスが設定されている(リンカオプションの-Rまたは
環境変数LD_RUN_PATHが設定されている)場合には、実行ファイルにライブラリ検索パスが
追加されるため、実行時にLD_LIBRARY_PATHの設定が必要ありません。

拡張子が.laのファイルがインストールされている場合は自動的に実行時パスが追加
されることがほとんどですが、zlibやopensslのライブラリのようにlibtoolを使用しない
アプリケーションのライブラリとリンクする場合にはconfigure完了後にconfig.status
を編集して自分で実行時パスを追加する必要があります。

# configureが終わったら、config.statusを開いて、例えばzlibであれば -lz と
# いう箇所を -lz -R/usr/local/libのように書き換えて ./config.status を実行し、
# その後 make する

> ソースインストールする際、./configureとmakeを実行する一般ユーザのPATHや
> LD_LIBRARY_PATHの示すパスと、
> make installを実行するrootユーザのPATHやLD_LIBRARY_PATHの示すパス
> (または順番)が異なっていても大丈夫でしょうか?

アプリケーションにも依ります。makeやmake install時にLD_LIBRARY_PATHが必要な
アプリケーションはほとんど無いと思います。

> exportなどによる一時的な設定ではなく、profieや/etc/ld.so.conf(solarisでは
> crleによる)などで固定で設定する場合、注意することはありますか?

認識されていることが全てでしょう。

よくWebを見ていると、Linux向けのサイトで/etc/ld.so.confに追加するような
記述があり、ミッション・クリティカルなシステムでもそれを真似ているケースも
散見されますが、OS全体に影響を与え下手するとOSの動きが変わってしまうリスク
さえあります。なので、できるだけ設定すべきではないでしょう。ましてや先頭に
追加するのはもってのほかです。極力影響度が少ない実行時パスやLD_LIBRARY_PATHを
使うのが望ましいでしょう。

> ソースインストールする際に、事前にPATHやLD_LIBRARY_PATHを設定してから、
> ./configure → make をするよう説明しているサイトがありますが、
> インストールするときだけPATHやLD_LIBRARY_PATHを変更しても問題ないのでしょうか?

インストールアプリによります。

/libまたは/usr/lib以外の場所にインストールされたライブラリとリンクされた場合、
基本的には実行するときもLD_LIBRARY_PATHの設定が必要になります。

ただし、インストール時に実行時パスが設定されている(リンカオプションの-Rまたは
...続きを読む


人気Q&Aランキング