gcc的头文件路径|C++头文件目录在那个文件夹

gcc的头文件路径|C++头文件目录在那个文件夹的第1张示图

『壹』 WINDOWS操作系统下的C语言头文件存放在哪个目录中

C语言中的头文件一般分为两类,一类是标准库头文件专,一类是用户自定义头文件属。

1、标准库头文件,不同的编译器都不相同。

Vc6.0一般在安装目录下的VC98INCLUDE目录,比如C:Program Files (x86)Microsoft Visual StudioVC98INCLUDE。

Vs一般在位于$VSPATHVCinclude路径下面。

gcc一般默认在 /usr/include目录下。

2、用户自定义头文件,存储位置有用户自定义。

(1)gcc的头文件路径扩展阅读:

在C语言中,头文件的作用如下:

1、加强类型检查,提高代码的类型安全性。

2、减少代码的重复书写,提高编写和修改程序的效率。 在程序开发的过程中,对某些数据类型或者接口进行修改是难免的,使用头文件,只需要修改头文件中的内容,就可以保证修改在所有源文件中生肖,从而避免了繁琐易错的重复修改。

3、提供保密和代码重用的手段。 用户只需要按照头文件的接口声明来调用库功能,而不必关心接口是怎么实现的,编译器会从库中提取相应的代码。

4、提供全局变量、全局函数的声明或提供公用数据类型的定义,从而实现分离变异或代码复用。

『贰』 linux下编写c++,include的那些头文件在什么地方

C/C++程序在linux下被编译和连接时,GCC/G++会查找系统默认的include和link的路径,以及自己在编译命令中指定的路径。

1、#include <stdio.h>,直接到系统指定目录去查找头文件。

系统默认路径为:/usr/include,/usr/local/include,/usr/lib/gcc-lib/i386-Linux/2.95.2/include(gcc库文件的路径,各个系统不一致)

2、#include "stidio.h",会先到当前目录查找头文件,如果没找到在到系统指定目录查找。

3、gcc编译时查找头文件,按照以下路径顺序查找:

gcc编译时,可以设置-I选项以指定头文件的搜索路径,如果指定多个路径,则按照顺序依次查找。比如,gcc -I /usr/local/include/node a.c

gcc会查找环境变量C_INCLUDE_PATH,CPLUS_INCLUDE_PATH中指定的路径。

(2)gcc的头文件路径扩展阅读:

应用程序代码编译过程:

编译器根据头文件提供的库函数接口形式,来编译代码,然后生成目标文件;然后,再使用链接器将这个目标文件与系统库链接;最终生成应用程序。代码包含了自己写的内容,还有系统提供好的现成的库函数,整个结合起来才形成一个完整的程序。

库函数的头文件,在编译的时候被使用,而库函数的代码段(库文件),在链接的时候被使用。

example:

应用程序代码在使用一个系统调用的时候,例如printf()函数,需要指定包含的头文件stdio.h;另外,在链接的时候对应的链接libc.a(笔者电脑文件所在目录:/usr/lib/i386-linux-gnu/libc.a)。

总结一下,编写应用程序,需要使用linux系统提供的库函数。具体实现起来,需要头文件和库文件。头文件是需要我们编写应用程序的时候,在源文件开头添加的;而库文件则需要配置编译环境进行指定搜索目录。

『叁』 gcc去哪找头文件

gcc默认会到/usr/include下面去找头文件,那就使用绝对路径吧!利用系统的环境变量。对于头文件的搜索路径:C_INCLUDE_PATH=<your include path;export C_INCLUDE_PATH对于库文件的搜索路径:LIBRARY_PATH=<your lib path;export LIBRARY_PATH对于链接程序ld使用的库文件搜索路径:LD_LIBRARY_PATH=<your ldlib path;export LD_LIBRARY_PATHgcc -I/usr/local/headers/ld:ld –verbose | grep SEARCH你echo $PATH,看看/usr/local/include是不是放在/usr/include前面了。PATH环境变量只是可执行程序的查找路径吧?gcc的include好象跟这个没关系

『肆』 如何指定GCC的默认头文件路径

GCC找头文件有三种策略:1.会在默认情况下指定到/usr/include文件夹(更深层次的是一个相对路径,GCC可执行程序的路径是/usr/bin,那么它在实际工作时指定头文件头径是一种相对路径方法,换算成绝对路径就是/usr/include)2.GCC还使用了-I指定路径的方式,这一点大家都知道3.还可以使用一个参数来指示GCC不搜索系统默认路径

『伍』 C语言头文件的位置

C语言中的头文件一般分为两类,一类是标准库头文件,一类是用户自定义头文件回。1、标准库答头文件,不同的编译器都不相同。Vc6.0一般在安装目录下的\VC98\INCLUDE目录,比如C:\Program Files (x86)\Microsoft Visual Studio\VC98\INCLUDE。Vs一般在位于$VSPATH\VC\include路径下面。gcc一般默认在 /usr/include目录下。2、用户自定义头文件,存储位置有用户自定义。

『陆』 gcc/g++ 如何指定链接库和头文件路径

GCC找头文件有三种策略:1.会在默认情况下指定到/usr/include文件夹(更深层次的是一个相对路径,GCC可执行程序的路径是/usr/bin,那么它在实际工作时指定头文件头径是一种相对路径方法,换算成绝对路径就是/usr/include)2.GCC还使用了-I指定路径的方式,这一点大家都知道3.还可以使用一个参数来指示GCC不搜索系统默认路径

『柒』 gcc的头文件搜索路径是怎么回事

gcc 预处理的时候需要找到相关的头文件来合成代码文件,头文件搜索路径包含了内置的路径和命令行(-I)中指定的路径。

gcc编译器搜索头文件路径

『捌』 gcc编译时默认使用的库在哪个目录

看你包含的头文件和使用的函数啊~两者包含的函数不一样~你要是使用fopen/memcpy等等这样标准C的函数,当然会在链接时使用到标准C库(ANSIC),如果你使用了read/write这些glibc库实现的函数,肯定就在链接时使用到glibc库~具体使用了什么库,要看你调用的函数了~可能不会仅仅只包含一个库~Linux下,库的路径一般是:/lib,/usr/lib,/usr/local/lib等,这些路径一般会在/etc/ld.so.conf中标记出来,如果需要添加特殊位置的库,可以把库的路径添加到/etc/ld.so.conf中去,并且执行ldconfig来使得新路径立即生效~

『玖』 C++头文件目录在那个文件夹

C++标准库头文件,不同的编译器默认路径不相同。

Vc6.0一般在专安装目录下的VC98INCLUDE目录,比如C:Program Files (x86)Microsoft Visual StudioVC98INCLUDE。

Vs一般在位于$VSPATHVCinclude路径属下面。

gcc一般默认在 /usr/include目录下

『拾』 gcc 在编译时如何去寻找所需要的头文件

当我们给$ gcc -o foo.o foo.cgcc怎么知道去哪里找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/specsgcc 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/includeEnd 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/includeEnd 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/includeprefix/includeprefix/xxx-xxx-xxx-gnulibc/includeprefix/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。

未经允许不得转载:山九号 » gcc的头文件路径|C++头文件目录在那个文件夹

赞 (0)