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选项会生成一些额外的调试信息