文档介绍：-
z.
Linu*环境下的编译，与库的使用
From: liu*/
为什么使用ullib有时会出现 undefined reference error 的错误？
为什么在动态库里ul_log会把日志输出到屏幕上？
辅助的机器码,帮它处理与系统底层打交道的事情.
gcc -o hello
. 我们提供的各种库头文件在编译期使用，到了期就需要用-l, -L的方式来指定我们到底需要哪些库。 对于glibc中的strlen之类常用的东西编译器会帮助你去加上可以不需要手动指定。
这个地方也是本文讨论的重点, 在后面会有更详细的说明
-
z.
小提示:
有些程序在编译的时候会出现 “linker input file unused because linking not done〞 的提示(虽然gcc不认为是错误,这个提示还是会出现的), 这里就是把 编译和 使用的参数搞混了,比方
g++ -c -I../../ullib/include -L../../ullib/lib/ -lullib
这样的写法就会导致上面的提示, 因为在编译的过程中是不需要的, 它们两个过程其实是独立的
静态
的过程 这里先介绍一下，器所做的工作，其实做的工作分两块: 符号解析和重定位
符号解析
符号包括了我们的程序中的被定义和引用的函数和变量信息
在命令行上使用
nm ./test
test 是用户的二进制程序，包括
可以把在二进制目标文件中符号表输出
009b8 A bss_start004cc t call_gmon_start009b8 b pleted. d CTOR_END00780 d CTOR_LIST009a0 D data_start009a0 W data_start00630 t do_global_ctors_au*004f0 t do_global_dtors_au*009a8 D dso_handle00798 d DTOR_END00790 d DTOR_LIST007a8 D DYNAMIC009b8 A edata009c0 A end00668 T fini00780 A fini_array_end00780 A fini_array_start00530 t frame_dummy00778 r FRAME_END00970 D GLOBAL_OFFSET_TABLE w gmon_start U g**_personality_v0C**ABI_1. T _init00780 A __init_array_end…
当然上面由nm输出的符号表可以通过编译命令去除，让人不能直接看到。
器解析符号引用的方式是将每一个引用的符号与其它的目标文件(.o)的符号表中一个符号的定义联系起来， 对于那些和引用定义在一样模块的本地符号(注:static修饰的),编译器在编译期就可以发现问题，但是对于那些全局的符号引用就比拟麻烦了．
下面来看一个最简单程序:
include
int foo();
int main() {
foo();
return 0;
}
, 采用下面的方式进展编译
g++ -c
-
z.
g++ -o test
第一步正常完毕，，到第二步的时候报了如下的错误
(.te*t+0*5): In function main':: undefined reference tofoo()’collect2: ld returned 1 e*it status
由于foo 是全局符号, 在编译的时候不会报错，等到的时候，发现没有找到对应的符号，就会报出上面的错误。但是如果我们把上面的写法改成下面这样
include//注意这里的static
static int foo();
int main() {
foo();
return 0;
}
在运行
g++ -c
, 马上就报出下面的错误:
:19: error: ‘int foo()’ used but never defined
在编译器就发现foo 无法生成目标文件的符号表，可以马上报错，对于一些本地使用的函数使用static一方面可以防止符号污染，另一方面也可以让编译器尽快的发现错误．
，(.o)的打包结果