GNU GCC查找路径

1.头文件

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

header file的搜寻会从-I开始

然后找gcc的环境变量 C_INCLUDE_PATH,CPLUS_INCLUDE_PATH,OBJC_INCLUDE_PATH

再找内定目录
/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
 
2.库文件
cos()等函式库的选项要多加 -lm
编译的时候:
gcc会去找-L

再找gcc的环境变量LIBRARY_PATH

再找内定目录 /lib /usr/lib /usr/local/lib 这是当初compile gcc时写在程序内的

-l参数和-L参数

-l参数就是用来指定程序要链接的库，-l参数紧接着就是库名，那么库名跟真正的库文件名有什么关系呢？就拿数学库来说，他的库名是m，他的库文件名是libm.so，很容易看出，把库文件名的头lib和尾.so去掉就是库名了

好 了现在我们知道怎么得到库名，当我们自已要用到一个第三方提供的库名字libtest.so，那么我们只要把libtest.so拷贝到/usr/lib 里，编译时加上-ltest参数，我们就能用上libtest.so库了（当然要用libtest.so库里的函数，我们还需要与libtest.so配套的头文件）

放在/lib和/usr/lib和/usr/local/lib里的库直接用-l参数就能链接了，但如果库文件没放在这三个 目录里，而是放在其他目录里，这时我们只用-l参数的话，链接还是会出错，出错信息大概是：“/usr/bin /ld: cannot find -lxxx”，也就是链接程序ld在那3个目录里找不到libxxx.so，这时另外一个参数-L就派上用场了，比如 常用的X11的库，它在/usr/X11R6/lib目录下，我们编译时就要用-L/usr/X11R6/lib -lX11参数，-L参数跟着的是库文 件所在的目录名。再比如我们把libtest.so放在/aaa/bbb/ccc目录下，那链接参数就是-L/aaa/bbb/ccc -ltest
另外，大部分libxxxx.so只是一个链接，以RH9为例，比如libm.so它链接到/lib/libm.s
o.x，/lib/libm.so.6又链接到/lib/libm-2.3.2.so，
如果没有这样的链接，还是会出错，因为ld只会找libxxxx.so，所以如果你要用到xxxx
库，而只有libxxxx.so.x或者libxxxx-x.x.x.so，做一个链接就可以了
ln -s libxxxx-x.x.x.so libxxxx.so
手工来写链接参数总是很麻烦的，还好很多库开发包提供了生成链接参数的程序，名字一般叫xxxx-config，一般放在/usr/bin目录下，比如
gtk1.2的链接参数生成程序是gtk-config，执行gtk-config --libs就能得到以下输出"-
L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic
-lgmodule -lglib -ldl -lXi -lXext -lX11 -lm"，这就是编译一个gtk1.2程序所需的g
tk链接参数，xxx-config除了--libs参数外还有一个参数是--cflags用来生成头文
件包含目录的，也就是-I参数，在下面我们将会讲到。你可以试试执行gtk-config 
--libs --cflags，看看输出结果
现在的问题就是怎样用这些输出结果了，最笨的方法就是复制粘贴或者照抄，聪明的办
法是在编译命令行里加入这个`xxxx-config --libs --cflags`，比如编译一个gtk程序：gcc gtktest.c `gtk-config --libs --cflags`这样
就差不多了。注意`不是单引号，而是1键左边那个键。
除了xxx-config以外，现在新的开发包一般都用pkg-config来生成链接参数，使用方法
跟 xxx-config类似，但xxx-config是针对特定的开发包，但pkg-config包含很多开发包的链接参数的生成，用pkg- config --list-all命令可以列出所支持的所有开发包，pkg-config的用法就是 pkg -config pagName --libs --cflags，其中pagName是包名，是pkg-config--list-all里列 出名单中的一个，比如gtk1.2的名字就是gtk+，pkg-
config gtk+ --libs --cflags的作用跟gtk-config --libs --cflags是一样的。比如：
gcc gtktest.c `pkg-config gtk+ --libs --cflags`

每个方法编译成一个.o文件，譬如printf.o,scanf.o等等。静态库（static library）就是这样一个解决方案。静态库是一个或多个.o文件的集合。程序员使用到这些.o文件对应的函数时，只需要在连接时提供该静态库即可，而不需要列举用到的.o文件。而连接器进行连接的时候，只会将程序中用到的函数对应的.o文件连接到程序中。譬如，我们有一个库文件libc.a，里面放有 printf.o,scanf.o等多个.o文件,如果我们程序中只使用了printf函数，那么，连接器只会将printf.o连接进来，而不会把 scanf.o也连接进来，虽然它们都同在一个库文件中。这样，计算机和程序员都满意了。是使用静态库的示例：


    静态库是在编译阶段跟应用代码连接在一起的，从那以后，两者就紧密耦合在一起。这样一来，应用代码中库文件的更新就成了大问题了。如果库文件更新了，我想在应用程序中使用到最新的静态库，那么，我只能够将我的代码跟新的静态库重新编译一次，很难维护。此外，静态库的性质使每一个应有程序都有静态库中相应部分的拷贝，譬如，程序A和B都用到了printf函数，那么在两个程序中都会有printf.o拷贝。如果系统中有好几十个进程都使用到了printf函数，那么相同的代码将会重复出现几十次，这对于内存是极大的浪费。针对这些问题，共享库 （shared library，也叫做动态连接库，*nix中为so文件，Windows中称为Dll）诞生了。使用该技术，一个共享库只会在系统中出现一次，而不管系 统中有多少个进程使用到这个共享库。同时，共享库中的代码段还可以被各个进程所共享。共享库的示例图：

     共享库是在应用代码装载到系统中的时候由动态连接器动态加载到内存空间去的。静态连接器在编译阶段只是在应用代码中插入一些关于共享库的基本信息，而不会 将共享库的实际代码连接到应用代码中去。这样，如果库文件更新了，我们只需要重新启动应用程序，就可以使用到最新的库文件了，同时，我们还大大节省了内 存，一举两得。
     现在，一切都那么美好，但是并非完美。现在的情况是在加载过程中我们会把应用代码中的使用到共享库动态加载到系统中，但是，这个库在实际运行过程中会被使用到吗？看下面例子：

void show(int cmd)
{
      if( cmd == 0 )
    {
        //use library method
     }
}

    如果传入的参数不等于 0 的话，libraay method是永远都不会执行的，但是，我们却会把这个共享库加载到系统中去。如果我们能够在运行过程中决定是否加载一个共享库，那该多好啊！完全可 以，Linux以及相关系统我们提供了相关的API，这些API包含在头文件<dlfcn.h>中。相关的函数有：

void *dlopen(const char *filename, int flag);
void *dlsym(void *handle, char *symbol);
int dlclose (void *handle);
const char *dlerror(void);

    在VC，也有相应的函数完成相关功能。此外，VC中还有延迟加载技术，使得Dll可以按需加载。

http://hi.baidu.com/daping_zhang/blog/item/594d0ff45958bc6eddc47487.html