动态库、静态库、头文件
Sudo apt-get update
虚拟机安装增强包/ubuntu/guide/2.html
编译时，编译器需要的是语法的正确，函数与变量的声明的正确。对于后者，通常是你需要告诉编译器头文件的所在位置（头文件中应该只是声明，而定义应该放在C/C++文件中），只要所有的语法正确，编译器就可以编译出中间目标文件。一般来说，每个源文件都应该对应于一个中间目标文件（O文件或是OBJ文件）。
链接时，主要是链接函数和全局变量，所以，我们可以使用这些中间目标文件（O文件或是OBJ文件）来链接我们的应用程序。链接器并不管函数所在的源文件，只管函数的中间目标文件（Object
File），在大多数时候，由于源文件太多，编译生成的中间目标文件太多，而在链接时需要明显地指出中间目标文件名，这对于编译很不方便，所以，我们要给中间目标文件打个包，在Windows下这种包叫“库文件”（Library
File)，也就是 .lib 文件，在UNIX下，是Archive File，也就是 .a 文件。
在编译时，编译器只检测程序语法，和函数、变量是否被声明。如果函数未被声明，编译器会给出一个警告，但可以生成Object
File。而在链接程序时，链接器会在所有的Object File中找寻函数的实现，如果找不到，那到就会报链接错误码（Linker
Error），在VC下，这种错误一般是：Link 2001错误，意思说是说，链接器未能找到函数的实现。你需要指定函数的Object
（.cn/s/blog_56aec1cb0100sfz4.html）&&&&&&&&&&&&
test.h中有函数sum(),mul()的声明，sum.c,mul.c必须include
test.h.否则能通过编译，但main.c无法与之链接。Main.c也要include test.h.
静态库的提出：
一个程序他所要用到的外部的函数和变量很多，于是他所要用到的目标模块也很多，1. 如果用gcc main.c sum.o
mul.o这样显式地写出，容易出错而且耗时，2.
如果把所有的可重定位目标模块整合成一个可重定位目标模块（如libc.o）,这样比较便利，但链接时main.o便需要与整个libc.o合并，生成可执行文件，这很浪费磁盘空间，并且对任何libc.o中函数的改变，都要求开发人员重新编译整个源文件，这使得维护变得复杂。
静态库，所有的相关源文件被编译成独立的目标模块（gcc &c mul.c sum.c），然后封装成一个单独的静态库文件（ar
rcs libtest.a mul.o
sum.o,r选项是replace的意思，当插入的模块已在库中存在，则替换同名模块，这样保证了只需编译一个源文件便可更新静态库。C是create的意思，创建静态库，s是往库中添加函数模块的意思，详见链接http://blog.csdn.net/freeman/article/details/6697278），在链接时，链接器只拷贝被程序引用的目标模块。静态库以一种存档的格式保存在磁盘。
g++ -c sum.c mul.c
ar rc libtest.a sum.o mul.o
g++ -c main.c
g++ -static main.o &L. &ltest&
（-l指定函数库名）&&
此时得到可执行文件a.out，并且就算删除了库libtest.a,它依然能正常执行
如果库要更新，比如要更新sum.c模块，只需
g++ -c sum.c
ar -r libtest.a sum.o
g++ -static main.c -L. &ltest
这样就会产生新的执行文件了。可以看出对库的更新无需编译全部的源文件。维护比较简单。但也可以看出她的一个缺点，如果函数库改变了，那么main.c要重新链接。并且在链接时她会把被程序引用的目标模块拷贝进来，这是很浪费磁盘空间的。详见（/view/f09a388acc22bcd126ff0c70.html）
于是提出了动态链接共享库(DLL)：
他在链接的时候并没有被拷贝进可执行文件中，可执行文件执行到相关函数时才调用该函数库的相应函数（共享库是一个目标模块，在运行时可以加载到任意的存储器地址，并和在存储器上的程序链接起来）因此使用动态库产生的可执行文件较小。
g++ -shared -fPIC -o libtest.so sum.c mul.c
（最后面的指定了库文件所在的路径,
并且库的路径指定死了的，无法修改，只要libtest.so移到别的目录下了，p就无法再执行。）
库中模块更改时只需再重新编译一下库g++ -shared -fPIC -o libtest.so sum.c
mul.ctest.c无需再编译，p的运行结果也会跟着模块一起变化了。
./p 运行正常
（静态执行链接）
./p（程序加载，动态完成链接过程，需要从是系统找到test库，因此要指定路径，都则报错）（ldd p 查看链接的库）
由于库文件在连接（静态库和共享库）和运行（仅限于使用共享库的程序）时被使用，其搜索路径是在系统中进行设置的。一般 Linux
系统把 /lib 和 /usr/lib
两个目录作为默认的库搜索路径，所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：（）
(1). 在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
设置方式：
export LD_LIBRARY_PATH=./:$LD_LIBRARY_PATH
可以用下面的命令查看 LD_LIBRAY_PATH 的设置内容：
(2). 在 /etc/ld.so.conf 文件中添加库的搜索路径。(或者在/etc/ld.so.conf.d
下新建一个.conf文件，将搜索路径一行一个加入-junziyang)
Sudo mkdir -p /root/test/env/lib
mv libpos.so /root/test/env/lib
编辑配置文件/etc/ld.so.conf，在该文件中追加一行"/root/test/conf/lib"。
/sbin/ldconfig
将自己可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。例如：
/usr/X11R6/lib
/usr/local/lib
需要注意的是：这种搜索路径的设置方式对于程序连接时的库（包括共享库和静态库）的定位已经足够了，但是对于使用了共享库的程序的执行还是不够的。这是因为为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，所以是直接读取库列表文件
/etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是一个非文本的数据文件，不能直接编辑，它是根据
/etc/ld.so.conf 中设置的搜索路径由 /sbin/ldconfig
命令将这些搜索路径下的共享库文件集中在一起而生成的（ldconfig 命令要以 root 权限执行）。
因此，为了保证程序执行时对库的定位，在 /etc/ld.so.conf 中进行了库搜索路径的设置之后，还必须要运行
/sbin/ldconfig 命令更新 /etc/ld.so.cache 文件之后才可以。ldconfig
,简单的说，它的作用就是将/etc/ld.so.conf列出的路径下的库文件缓存到/etc/ld.so.cache
以供使用。因此当安装完一些库文件，(例如刚安装好glib)，或者修改ld.so.conf增加新的库路径后，需要运行一下
/sbin/ldconfig使所有的库文件都被缓存到ld.so.cache中，如果没做，即使库文件明明就在/usr/lib下的，也是不会被使用的，结果编译过程中抱错，缺少xxx库，去查看发现明明就在那放着，搞的想大骂computer蠢猪一个。
在程序连接时，对于库文件（静态库和共享库）的搜索路径，除了上面的设置方式之外，还可以通过 -L 参数显式指定。因为用 -L
设置的路径将被优先搜索，所以在连接的时候通常都会以这种方式直接指定要连接的库的路径。
这种设置方式需要 root 权限，以改变 /etc/ld.so.conf 文件并执行 /sbin/ldconfig
命令。而且，当系统重新启动后，所有的基于 GTK2 的程序在运行时都将使用新安装的 GTK+ 库。不幸的是，由于 GTK+
版本的改变，这有时会给应用程序带来兼容性的问题，造成某些程序运行不正常。为了避免出现上面的这些情况，在 GTK+
及其依赖库的安装过程中对于库的搜索路径的设置将采用另一种方式进行。这种设置方式不需要 root 权限，设置也简单。#include
void print_hello() {
& printf("Hello World\n");
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH export
LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
libhello.so =& ./libhello.so (0x6d000)
libc.so.6 =& /lib64/tls/libc.so.6 (0x6e000)
/lib64/ld-linux-x86-64.so.2 (0x56000)
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。用gcc编译gtk生成exe怎么静态连接在其他电脑也能运行_gtk吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：683贴子：
用gcc编译gtk生成exe怎么静态连接在其他电脑也能运行收藏
求大神解答
可能在这方面还有许多认识的误区 提的问题不懂符合逻辑不
缺牙要及时修复，揭秘种植牙如何做到几十年不掉？
为什么没人回复呢
不知道怎么静态链接我一直用这个....gtk+ 3.14.5 for windows
跪求大神指导 怎么用editplus搭建gtk环境
build_gtk_win32.bat.....
或者用Dev-C++ .............
登录百度帐号推荐应用
为兴趣而生，贴吧更懂你。或-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.so.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程序所需的gtk链接参数，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`。
阅读(...) 评论()静态库链接动态库时，如何使用该静态库 - 博客频道 - CSDN.NET
newchenxf的专栏
分类：编译处理
码字辛苦，转载请注明出处喔！
网上有各种静态库的创建&使用的例子，但都是超级简单的例子，比如，静态库，就直接来个printf()，就完事了！
其实，实际使用时，静态库会复杂很多，比如会调用很多其他的动态库。
下图就是个例子：
假设libXXX.a用了libpthread.so的函数“pthread_create”，那libXXX.a在链接时，有没有把“pthread_create”函数copy到自己身上，使其完全独立？main.c在链接时，只需要链接libXXX.a，还是连libpthread.so也要链接？！这就是我要讨论的内容！
为了证实问题，我们写个测试程序吧。一个是libXXX.a，一个是main.c。
1 静态库文件libXXX.a源代码
static_lib_example.h
#ifndef STATIC_LIB_EXAMPLE_H_INCLUDED
#define STATIC_LIB_EXAMPLE_H_INCLUDED
int testFunc(int x);
static_lib_example.c
#include "static_lib_example.h"
#include &stdio.h&
#include &pthread.h&
void *thread_exe(void *x_void_ptr)
int *x_ptr = (int *)x_void_
while(++(*x_ptr) & 100);
printf("x increment finished\n");
return NULL;
int testFunc(int x)
printf(" testFunc %i\n",x);
pthread_t inc_x_
if(pthread_create(&inc_x_thread, NULL, thread_exe, &y)) {
fprintf(stderr, "Error creating thread\n");
一个头文件，一个原文件，很简单。
好吧，然后得来个Makefile
OUT_LIB = libstatic_lib_example.a
LIB_SRC := static_lib_example.c
TEMP_O := static_lib_example.o
$(TEMP_O): $(LIB_SRC)
@gcc -c -o $@ $^
$(OUT_LIB)
$(OUT_LIB): $(TEMP_O)
@ar rcs $@ $^
@rm -r *.a *.o
其实Makefile相当于2句命令。所以你不写Makefile，敲下面2句command也行。
gcc -c static_lib_example.c -o static_lib_example.o
ar rcs libstatic_lib_example.a static_lib_example.o
好了，编译结果如下：
libstatic_lib_example.a
static_lib_example.c
static_lib_example.h
static_lib_example.o
2. 调用静态库的程序main.c源代码
我们就写一个main.c，它会链接libstatic_lib_example.a，并调用函数testFunc(int x)
#include "static_lib_example.h"
int main(int argc, char* argv[])
testFunc(100);
3 编译main.c的情况分析
编译main.c（只需要一个命令，就不写Makefile啦）
gcc -g -O3 -Wall main.c -o main
-I/home/chenxf/static_lib_sample/ -L/home/chenxf/static_lib_sample/ -lstatic_lib_example
-I表示头文件的路径
-L表示库的路径，即libstatic_lib_example.a的路径。
上面的命令，表示main程序，只链接静态库libXXX.a。（好吧，就是libstatic_lib_example.a啦，干嘛这么纠结名字！^^）
/home/chenxf/static_lib_sample/libstatic_lib_example.a(static_lib_example.o)：在函数‘testFunc’中：
static_lib_example.c:(.text+0x86)：对‘pthread_create’未定义的引用
static_lib_example.c:(.text+0xd4)：对‘pthread_join’未定义的引用
collect2: error: ld returned 1 exit status
出错啦！！！！！！
在main.c链接的时候，说找不到pthread_create了！
看来，静态库libXXX.a并没有把动态库的函数copy到自己身上，只留了符号表，所以main.c要用libXXX.a时，还必须链接动态库libpthread.so。也就是
gcc -g -O3 -Wall main.c -o main
-I/home/chenxf/static_lib_sample/ -L/home/chenxf/static_lib_sample/ -static -lstatic_lib_example -lpthread
（libpthread.so在默认的系统库目录/usr/lib，不需要再写-L/usr/lib/）
这样一写，就OK啦！编译就成功了！
我们还可以用 nm 工具，来确认libXXX.a到底有木有把pthread_create()函数copy到自己身上。
chenxf@chenxf-PC:~/static_lib_sample$ nm libstatic_lib_example.a
static_lib_example.o:
U pthread_create
U pthread_join
0040 T testFunc
0000 T thread_exe
U表示仅仅调用，而没有定义。也就是该库并不独立，而是依赖于其他库，比如libpthread.so
总结一下成果吧！
如果有静态库libXXX.a，它有个函数叫testFunc()，该函数用了其他的动态库的函数，比如libAA.so的AA()函数，libBB.so的BB()函数，libCC.so的CC()函数，那么，该libXXX.a对这些动态库的调用仍是动态调用，而不是把动态库的相关函数copy到自己身上。
任何其他程序，想用libXXX.a，链接时都需要链接libXXX.a所依赖的动态库。
至于程序跑起来时，动态库是否要在现场？这个就跟编译程序加不加-static有关系了。
请看我另一博文就知道。
anyway，知道真相的你，是不是觉得静态库不方便？！
我也觉得！
个人看法是，如果你要写的静态库libXXX.a是完全独立的，比如里面只有一些数学运算，不依赖与其他动态库，那静态库挺好的，任何用他的程序，只需要链接时用到，程序跑起来，就不需要它在现场了！
但是，如果你要写的库，依赖很多其他的库，那你还是改写成动态库吧！否则，作为写其他程序的人，如果要用你的库，那写Makefile时，还得知道你到底依赖了什么动态库，否则编译都编译不过，多痛苦啊！！！
给出源码。
排名：千里之外
（2）（3）（1）（2）（1）（4）（4）