g編譯頭文件路徑

A. Makfile，求指點：編寫makefile來編譯文件時，指定了頭文件路徑，但是報庫函數的東西未聲明，咋回事

直接編在一起就可以了啊

B. 目錄下有個.h.gch文件，是什麼

所謂預編譯頭，就是把頭文件事先編譯成一種二進制的中間格式，供後續的編譯過程使用。GCC編譯頭文件後的中間文件是*.gch。 g++ xxx.h 把.h文件當成.cpp文件一樣來編譯。如果需要控制編譯細節，比如常量定義之類，可加上其它選項。運行之後，會在同個目錄里生成一個名叫xxx.h.gch的文件。 注意在編譯.gch的過程中，GCC並沒有使用環境變數或 -I 選項來查找被編譯的頭文件，被編譯的頭文件必須在當前目錄下。然而，被編譯的頭文件所進一步包含的其它頭文件，卻可以通過以上途徑找到。簡言之，就是把直接編譯的那個頭文件以類似對待.cpp文件的方式處理了。 使用過程中，照搬一些stdafx.h相關的注意事項，它們同樣適用於.gch文件：應該把那些不常修改的（首當其沖，當然是系統的）頭文件放在預編譯頭里，而那些屬於你的程序的一部分的頭文件，一般並不放在預編譯頭里，因為它們可能隨時要被修改的。每修改一次就要重新生成預編譯頭，並沒有速度優勢可言，失去預編譯頭的意義了。另外重要的注意事項是：如果你生成預編譯頭的時候用了一些選項，比如宏定義，那麼使用這個預編譯頭的其它源代碼文件，被編譯的時候也要使用這些選項，否則會因為不匹配而編譯失敗。 使用預編譯後的文件時，只要包含其所對應的.h文件即可！比如頭文件叫foo.h，另外有一大堆其它文件都包含了這個foo.h，原來沒有使用預編譯頭技術，現在忽然想使用了，於是把foo.h編譯成了foo.h.gch。那其它文件要做怎樣的修改？——什麼都不用，一切照舊！聰明的GCC編譯器在查找一個.h文件之前，會自動查找其目錄里有沒有對應的.gch文件，如有，且可用，則用之；沒有，才用到真正的.h頭文件。——慢著，「如有，且可用」，什麼叫「可用」？——就是指這個.gch格式要正確，版本要兼容，而且如上所述，編譯兩者要用同樣的選項。如果.gch不可用，編譯器會給出一條警告，告訴我們：這個預編譯頭不能用！我只好用原有的.h頭文件啦！什麼？你說看不到這個警告？——當然，要先打開 -Winvalid-pch 選項才行，其默認是關閉的。 用 -H 選項感受一下預編譯頭的清爽吧！再沒有滾不完的頭文件了，明顯提高的速度，絕對會讓你有種翻身解放的感覺，原來MinGW也可以和蝸牛般的速度說再見的。

C. linux下C語言的庫函數的頭文件放在哪個目錄下啊

一般來說是放在來/usr/include目錄下的；

但是這個源並不局限也是可控的，如果我們進行開發過程中， 就會在內核的庫函數文件目錄：

例如在:/XXX/XXX/linux-X.X/include

所以根據不同的情況，頭文件存放的目錄也是不同的，具體需要可以根據locate和grep命令進行查詢。

D. linux gcc編譯參數有什麼用

-g 可執行程序包含調試信息：加個-g 是為了gdb 用，不然gdb用不到。

-o 指定輸出文件名（o：output）-o output_filename，確定輸出文件的名稱為output_filename，同時這個名稱不能和源文件同名。如果不給出這個選項，gcc就給出預設的可執行文件a.out。

-c 只編譯不鏈接：產生.o文件，就是obj文件，不產生執行文件（c : compile）。

gcc filename.c -o filename
上面的意思是如果你不打 -o filename（直接gcc filename.c ）；那麼默認就是輸出a.out.這個-o就是用來控制輸出文件的。用./a.out 執行文件。

其他參數含滲櫻扮義：

1、-ansi

關閉 gnu c中與 ansi c 不兼容的特性, 激活 ansi c 的專有特性（包括禁止一些 asm inline typeof 關鍵字, 以及 UNIX,vax 等預處理宏）。

2、-fno-asm

此選項實現 ansi 選頌孫項的功能的一部分，它禁止將 asm, inline 和 typeof 用作關鍵字。

3、-fno-strict-prototype

只對 g++ 起作用, 使用這個選項, g++ 將對叢灶不帶參數的函數,都認為是沒有顯示的對參數的個數和類型說明,而不是沒有參數。

而 gcc 無論是否使用這個參數, 都將對沒有帶參數的函數, 認為沒有顯示說明的類型。

4、-fthis-is-varialble

就是向傳統 c++ 看齊, 可以使用 this 當一般變數使用。

5、-fcond-mismatch

允許條件表達式的第二和第三參數類型不匹配, 表達式的值將為 void 類型。

6、-funsigned-char 、-fno-signed-char、-fsigned-char 、-fno-unsigned-char

這四個參數是對 char 類型進行設置, 決定將 char 類型設置成 unsigned char(前兩個參數)或者 signed char(後兩個參數)。

7、-include file

包含某個代碼,簡單來說,就是便以某個文件,需要另一個文件的時候，就可以用它設定，功能就相當於在代碼中使用#include<filename>。

E. GC++編譯器中怎麼沒有這個頭文件啊#include<conio.h>

有的編譯器有，有的沒有，一般用stdio.h，conio.h有的東西他都有吧

F. gcc 在編譯時如何去尋找所需要的頭文件

當我們給

$ gcc -o foo.o foo.c

gcc怎麼知道去哪裡找foo.c裡面所include的header文件,連結資料庫與系統定義呢? 總共有下列來源指定gcc去那找。
當初在編譯時指定的(在~gcc/gcc/collect2.c:locatelib()
寫在specs內的
後來用-D -I -L指定的
gcc環境變數設定(編譯的時候)
ld.so的環境變數(這是run time的時候)
在

prefix/lib/gcc-lib/xxxx-xxx-xxx-gnulibc/2.9.5/

裡面有個很重要的specs這個檔案 gcc根據這個檔，做一些內定的動作。 通常系統上的specs內定裝起來是在

/usr/lib/gcc-lib/xxxx-gnulibc/version/

specs檔看起來是像這樣

*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}

*asm_final:
%|

*cpp:
%(cpp_cpu) %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{posix:
-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}

*cc1:
%(cc1_cpu) %{profile:-p}

*cc1plus:

*endfile:
%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s

*link:
-m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static:
%{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker
/lib/ld-linux.so.2}} %{static:-static}}}

*lib:
%{shared: -lc --version-script libgcc.map%s} %{!shared: %{mieee-fp:-lieee}
%{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}}

*libgcc:
-lgcc

*startfile:
%{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s}
%{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s}
%{shared:crtbeginS.o%s}

*switches_need_spaces:

*signed_char:
%{funsigned-char:-D__CHAR_UNSIGNED__}

*predefines:
-D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -Asystem(posix)

*cross_compile:
0

*version:
egcs-2.91.66

*multilib:
. ;

*multilib_defaults:

*multilib_extra:

*multilib_matches:

*linker:
collect2

*cpp_cpu_default:
-D__tune_i386__

*cpp_cpu:
-Asystem(unix) -Acpu(i386) -Amachine(i386) %{!ansi:-Di386}
-D__i386 -D__i386__ %{march=i486:-D__i486 -D__i486__}
%{march=pentium|march=i586:-D__pentium -D__pentium__ }
%{march=pentiumpro|march=i686:-D__pentiumpro -D__pentiumpro__ }
%{m386|mcpu=i386:-D__tune_i386__ } %{m486|mcpu=i486:-D__tune_i486__ }
%{mpentium|mcpu=pentium|mcpu=i586:-D__tune_pentium__ }
%{mpentiumpro|mcpu=pentiumpro|mcpu=i686:-D__tune_pentiumpro__ }
%{!mcpu*:%{!m386:%{!m486:%{!mpentium*:%(cpp_cpu_default)}}}}

*cc1_cpu:
%{!mcpu*: %{m386:-mcpu=i386} %{mno-486:-mcpu=i386 -march=i386}
%{m486:-mcpu=i486} %{mno-386:-mcpu=i486 -march=i486}
%{mno-pentium:-mcpu=i486 -march=i486} %{mpentium:-mcpu=pentium}
%{mno-pentiumpro:-mcpu=pentium} %{mpentiumpro:-mcpu=pentiumpro}}

在shell下用這行，-E 表示只做到preprocess就好

$ echo 'main(){}' | gcc -E -v -

你會看到gcc去讀specs檔

Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 20000220 (Debian GNU/Linux)
/usr/lib/gcc-lib/i386-linux/2.95.2/cpp -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -
GNU CPP version 2.95.2 20000220 (Debian GNU/Linux) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc-lib/i386-linux/2.95.2/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../include/g++-3
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../i386-linux/include
End of omitted list.
# 1 ""
main(){}

所以有內定的定義，(就是用在#if defined #ifndef #define這些東西， 如果有定義這個字元串，就去編譯等等。) -Dxxxx -Dxxxx -Axxxx。 還有內定的include文件的搜尋路徑

/usr/include
/usr/local/include
/usr/lib/gcc-lib/i386-linux/2.95.2/include
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../include/g++-3
/usr/lib/gcc-lib/i386-linux/2.95.2/../../../../i386-linux/include

但是如果裝gcc的時候，是有給定的prefix的話，那麼就是

/usr/include
prefix/include
prefix/xxx-xxx-xxx-gnulibc/include
prefix/lib/gcc-lib/xxxx-xxx-xxx-gnulibc/2.8.1/include

所以header file的搜尋會從-I開始然後找gcc的環境變數 C_INCLUDE_PATH,CPLUS_INCLUDE_PATH,OBJC_INCLUDE_PATH 再找上述的內定目錄
函式庫
當我們用到數學函式cos()，cos這個symbol，gcc並不曉它到底是什麼東西， 是變數，是函式，要預留多少空間給他等等，完全沒有任何訊息，你必須標頭 檔要#include ，gcc才知道。而且因為specs這個檔裡面只有要 link -lc也就是只有libc.so這個檔內的symbol會被搜尋， 像printf scanf等都在這裡面，可是像cos()等就沒有了， 所以函式庫的選項要多加 -lm ，這時ld才會來找libm這個函式庫，
編譯的時候，gcc會去找-L，再找gcc的環境變數LIBRARY_PATH，再找內定目錄 /lib /usr/lib /usr/local/lib 這是當初compile gcc時寫在程序內的， gcc環境變數與pass給ld的機制在~gcc/gcc/collect2.c下找得到。 這上面只是搜尋路徑而已，如果要不加-lm 也能正確的主動搜尋某個特定的lib，例如libm， 就要去在specs這個檔案改一下，把math這個函式庫加進自動聯結函式庫 之一。就不用寫-lm了。
RUN TIME的時候， 如果編譯時沒有指定-static這個選項，其實可執行文件並不是真的可執行， 它必須在執行(run time)時需要ld.so來做最後的連結動作，建造一個可執行的 image丟到內存。如果是靜態連結，編譯時ld會去找libm.a的檔 。如果是動態連結去找libm.so。 所以每次有新改版程序， 或新加動態函式庫如果不在原本的/etc/ld.so.conf搜尋路徑中，都要把路徑 加進來，然後用

ldconfig -v

會重建cache並且顯示它所參照的函式庫。Run Time時ld.so才找得到lib"執行"。 ld與ld.so不一樣喔。
一些重要的程序

ld :Link Editor 連結各obj寫進一個可執行檔(executable)。
ldd :秀出一個執行文件用了那些動態函式庫。
ld.so :Dynamic Linker, 動態連結的話，是由ld.so完成執行時期symbol的
:參照與連結。
ld-linux.so :ELF文件的動態連結，跟ld.so一樣。只是ld.so是給a.out format的。
:新的glicb2的ld-linux.so.2已經跟ld.so.2結合成單一程序了。
ldconfig :根據/etc/ld.so.conf內的目錄，做出動態連結所需的cache檔。

ld 就是負責各個函式庫文件的信息寫進最後可執行檔(executable)，所以它叫做 link editor，編譯時根據flags -L搜尋需要的lib，gcc也會把他的設定pass下來。 ld.so ld-linux.so.2是負責最後動態連結，叫做dynamic linker， RUN Time 執行程序時,它根據這個順序搜尋函式庫。
LD_LIBRARY_PATH 或LD_AOUT_LIBRARY_PATH環境變數所指的路徑
ldconfig所建立的cache
/lib /usr/lib內的檔
來找程序所需要的動態函式庫
ldconfig會根據/etc/ld.so.conf這個檔的設定，加上內定的兩個目錄 /lib /usr/lib來設定ld.so要用到所需要的連結 以及連結的cache到/etc/ld.so.cache。 所以如果換了新的函式庫，新的kernel，內部的標頭檔可能會有變化， 都要跟著改變讓gcc正確的找到，喔不，應該是cpp, ld, ld.so能正確的找到。 不然編出來的執行檔可能是錯誤的，執行時還可能segmentation fault。

G. 用G++編譯時老報一些找不到頭文件的錯，但GCC就沒有

通常找不到指定函數不是因為編譯參數問題。而是你
g.cpp
中在include
f.h的時候沒有使用：
extern
"C"
{
#include"f.h"
}
因為C語言和cpp的編譯過程中的函數名稱修飾規則是不一樣的。當cpp引用C庫的時候必須告訴
編譯器
，哪些函數是
C函數

H. 怎樣編譯和配置GStreamer

GStreamer無疑是一個美觀的設計，但初學者往往覺得結構復雜，難以掌握。編譯起來也很麻煩：）茄舉芹 本文列出了編譯和配置GStreamer的主要步驟，給需要的人提供答嫌一個參考。 像其它的Linux開源項目一樣，GStreamer也是採用包括autoconf,automake在內的GNU build system來編譯的。而且，GStreamer在編譯和安裝時還要依賴於其它的庫，這些庫至少包括：pkg-configGLiblibxml2 liboil 這些庫都使用pkg-config來提供include路徑和library路徑等編譯信息，而不是像很多開源項目一樣在執行configure腳本的時候用CPPFLAGS/CFLAGS環境變數來指定。 這些庫很容易通過google找到，一般以「*.tar.gz」或「*.tar.bz2」壓縮文件的形式存在。使用tar命令解壓：tar xzf *.tar.gz或tar xjf *.tar.bz2 解壓後一般會生成一個源文件目錄，先面的命令都要進入到各個顫畢庫的源文件目錄內執行。 具體編譯和安裝步驟如下： （1）確定各個庫的安裝路徑。為描述方便，假設如下的安裝路徑：pkg-config: /usr/local/install-pkg-config/Glib: /usr/local/install-glib/libxml2: /usr/local/install-libxml2/liboil: /usr/local/install-liboil/GStreamer Core: /usr/local/install-gstcore/GStreamer Base Plugins: /usr/local/install-plugins-base/ （2）設置環境變數。下面的命令按bshell/bash的語法，cshell中應該用setenv。 export PATH=/usr/local/install-pkg-config/bin:$PATH export PKG_CONFIG_PATH="/usr/local/install-glib/lib/pkgconfig:/usr/local/install-libxml2/lib/pkgconfig:/usr/local/install-liboil/lib/pkgconfig:/usr/local/install-gstcore/lib/pkgconfig:/usr/local/install-plugins-base/lib/pkgconfig" 第一個命令是將pkg-config這個工具加入到PATH變數中，這樣在執行configure腳本時就能夠調到剛剛安裝好的pkg-config。 第二個命令是設置pkg-config的搜索路徑，在執行configure腳本時會調用pkg-config得到所依賴的頭文件和庫。 （3）編譯和安裝pkg-config。 ./configure --prefix=/usr/local/install-pkg-configmakemake install 執行configure腳本時用--prefix指定安裝路徑 （4）編譯和安裝GLib。 ./configure --prefix=/usr/local/install-glibmakerm -rf /usr/local/install-glib/include/glib.h /usr/local/install-glib/include/gmole.h make install （5）編譯和安裝libxml2。 ./configure --prefix=/usr/local/install-libxml2makemake install （6）編譯和安裝liboil。 ./configure --prefix/usr/local/install-liboilmakemake install （7）編譯和安裝GStreamer Core。 ./configure --prefix=/usr/local/install-gstcoremakemake check (optional) make install （8）編譯和安裝GStreamer Base Plugins。 ./configure --prefix=/usr/local/install-plugins-basemakemake check (optional) make install （9）編譯和安裝GStreamer的其它plugins，包括gst-plugins-good，gst-plugins-bad等。可選。與編譯安裝gst-plugins-base類似。 （10）設置運行環境。要運行GStreamer，需要設置GST_PLUGIN_PATH環境變數，指明GStreamer Core和Plugins的庫路徑。 export GST_PLUGIN_PATH="=/usr/local/gst/install-gstcore/lib:=/usr/local/install-plugins-base/lib" 如果還安裝了其它plugins,也要加到GST_PLUGIN_PATH路徑里。 另外，如果已有的tool chain版本不夠，還需要更新tool chain。常需要做的是安裝新版本的autoconf和automake。

I. LINUX下如何用G++編c++,給一個詳細的實例就好

g++是用來編譯c++程序的，假如你想生成名為test的可執行文件，源文件為1.cpp的話，使用g++ -o test 1.cpp即可，執行時執行./test

J. gcc編譯器頭文件處理

兩次相對比一下，第二次增加了以下函數的實現，這部分是要編譯成機器指令的，所以第二次這部分相當於是增加的。

intprintf(constchar*__format,...)
{
registerint__retval;
__builtin_va_list__local_argv;__builtin_va_start(__local_argv,__format);
__retval=__mingw_vprintf(__format,__local_argv);
__builtin_va_end(__local_argv);
return__retval;
}

那第二次減少了哪些呢？一點都沒有，因為stdio這個頭文件聲明的函數和變數，都是在一個庫中實現的，根本就不會包含在你的exe中，所以加不加stdio頭文件沒有區別。

要想驗證這個也很簡單：代碼1

#include<stdio.h>
intmain(){return0;}

代碼2：

intmain(){return0;}

比較這兩次產生的exe是否一致即可。

注意，不能帶有-g選項，-g選項會生成一些額外的調試信息