库的名称：去掉前面的 lib 去掉后面的 .a(版本号) .so(版本号) 剩下的，才是库正真的名称。
查看文件依赖库：ldd
1. 打包成静态库
ar -rc [lib库的名称.a] [需要打包的.o文件]
r : replace （更新替换）
c：create （建立）
2. 打包成动态库（共享库）
- 使用
gcc -fPIC创建.o文件
- （PIC）position ignoring code 与位置无关码
gcc -fPIC -c [.c文件]
- 用
gcc -shared打包.o文件
- -shared 共享库 / 动态库
gcc -shared -o [lib动态库名.so] [需要打包的.o文件]
3. 使用第三方静态库
当我们有了一个库，接下来，要将库引入我们的项目，必须要让编译器找到 库 和 头文件
- 需要指定的 头文件 和 库文件
- 如果没有默认安装到系统 gcc、g++ 默认的搜索路径下，用户必须指明对应的选项，告知编译器：
-
- 头文件在哪里
-
- 库文件在哪里
-
- 库文件具体是谁
- 如果我们下载下来的库和头文件，拷贝到系统默认路径下，就叫做，在 Linux 下安装库
- 如果我们安装的库是第三方的（语言、操作系统系统接口就是第一方和第二方）库，我们要正要使用，即使是全部都安装到了系统中，gcc 和 g++ 都必须使用
-l来指明具体库的名称
gcc -o mytest main.c -I[头文件的路径] -L[库的路径] -l[去头尾的库名]
-L：后接 库 的路径（可以用 . ..），可以带空格也可以不带空格，
-I：后接 头文件 的路径（可以用 . ..），可以带空格也可以不带空格，
-l：后接 链接的 库名（去头去尾），可以带空格也可以不带空格
注意：静态链接形成的可执行程序，本身就有静态库中对方法的实现。 也就是说使用静态链接注定 会占用更多的资源。占用哪些资源呢？磁盘、可执行程序体积变大加载占用内存、下载周期变长、占用网络资源
4. 使用第三方动态库
使用静态库的方法，让我们把路径和名称给了编译器，OS 可以通过链接原则，即，将用户使用的二进制代码直接拷贝到目标可执行程序中。
但动态库不是这样的。还需要将 .so 文件放到系统的默认路径下，才能被 OS 找到。
运行时，OS 查到动态库的方法：
-
环境变量：向
LD_LIBRARY_PATH中添加库所在的路径
这是一个临时方案，此方法重启机器就无效了 -
在
/lib64/或/user/lib64下创建第三方库的 软链接
sudo ln -s [被链接路径] /lib64/[库名]
- 在系统路径
/etc/ld.so.conf.d/中 添加配置文件，写入 第三方库的路径
# 1. 在对应系统路径下添加一个配置文件
sudo touch /etc/ld.so.conf.d/[myconf.conf]
# 2. 将第三方库的所在位置，添加到文件中
sudo vim /etc/ld.so.conf.d/[myconf.conf]
# 3. 让 ld 路径下的系统配置文件生效
sudo ldconfig
5. 动态库的加载
只要我们把库加载到了内存，映射到进程的地址空间（共享区）中之后，我们的代码执行库中的方法时，就依旧还是在自己的地址空间内进行函数跳转即可。
不管有多少进程，动态库只会加载一份，是很节省资源的。
库中的地址，怎么理解？
动态库必定面临一个问题：
不同的进程，运行程度不同，需要使用的第三库是不同的，注定了，每一个进程的共享区中空闲的位置是不确定的。动态库中的地址，是不能确定的，所以使用库时绝对不能使用绝对地址。
动态库中的所有地址都是偏移量，默认从 0 开始。
当一个库，真正的被映射进地址空间的时候，它的起始地址才能真正确定。所以我们调用动态库的时候，选取地址的方法是：该进制中这个库真正的起始地址 + 调用方法的偏移量。如此一来，库就可以在进程的地址空间中随便加载，与我们具体加载到地址空间的什么位置就毫无关系了。
6. 注意事项
- 动态库和静态库同时存在时，系统默认采用动态链接
需要连接静态则，需要给出参数 -static
gcc -o mytest main.c -I[头文件的路径] -L[库的路径] -l[去头尾的库名] -static
-
编译器，在链接的时候，如果提供的库既有动态又有静态，优先采用动态链接。如果只有静态的话，直接静态链接。
-
静态的库删了不影响可执行程序运行，而动态的少了就不能跑了。
-
云服务器一般只有动态库，静态库需要自己安装
c 的静态库
sudo yum install -y glibc-static
c++ 的静态库
sudo yum install -y libstdc++-static
1145
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
