linux中把.c的文件编译成.so

Posted 2023-03-19

就跟用VS编译dll或者lib文件差不多，把代码编译完成以后，命名为相应的后缀就好了。
例如：
gcc
-c
-fPIC
libst.c
生成
libst.o
然后
gcc
-shared
-fPIC
-o
libst.so
libst.o
生成
libst.so
动态链接库
把libst.so拷贝到系统默认库目录下，比如
/lib,
/usr/lib
下
假定有
test.c
要引用这个库
gcc
-lst
-o
test
test.c
然后就可以了
假如不能把libst.so拷贝到默认库目录下，比方说放在了
/home/aaa/lib
下
那么就用这样的语句来编译test.c
gcc
-L/home/aaa/lib
-lst
-Wl,-rpath=/home/aaa/lib
-o
test
test.c 参考技术A 首先
gcc
-c
-fPIC
libst.c
生成
libst.o
然后
gcc
-shared
-fPIC
-o
libst.so
libst.o
生成
libst.so
动态链接库
把libst.so拷贝到系统默认库目录下，比如
/lib,
/usr/lib
下
假定你有
test.c
要引用这个库
gcc
-lst
-o
test
test.c
然后就可以了
假如不能把libst.so拷贝到默认库目录下，比方说放在了
/home/aaa/lib
下
那么就用这样的语句来编译test.c
gcc
-L/home/aaa/lib
-lst
-Wl,-rpath=/home/aaa/lib
-o
test
test.c

GCC编译选项

 

• 编译与链接

编译（compile）：将.c或.cpp文件编译成.o(linux)或者.obj(windows)文件，也称为中间目标文件

链接（link）：将.o或.obj链接成可执行文件，windows下是.exe结尾，Linux没有限制，一般不带有后缀名

库文件：大型项目编译时生成的目标文件太多，主要是给中间目标文件打包

静态 => .a .lib，在链接时生成执行文件

动态 => .so .dll，由执行文件运行时加载

 

• 实例，选项一般无先后关系

gcc xxx.c，编译成功后默认生成a.out执行文件 => ./a.out

gcc  xxx.c -o demo 或 gcc -o demo xxx.c 

gcc  xxx.o -o demo

gcc  xxx.c -S demo.s

gcc  xxx.i -o demo

 

• 选项：
• -v，打印较多的编译信息
• -x，指定编译雨语言，缺省情况编译器根据文件末尾格式来确定
• -o，输出指定执行文件
• -Wall，打开警告选项，建议开启
• -w，不生成任何警告信息
• -E，仅预处理，生成.i文件
• -S，仅编译到汇编，生成.s文件
• -C，编译到目标代码，生成.o文件，通过最后一步链接生成目标文件
• -M，自动寻找源文件找包含的头文件，如 gcc -M main.c，此时在依赖项中不必填写需要引入的头文件。-M有可能会包含多余的头文件，可以才用-MM
• -I/usr/local/include，引入头文件目录
• -L/usr/local/lib，引入库文件地址
• -lliblua.a，引入库文件liblua.a
• -shared,生成共享的库文件，生成动态库需要与-fPIC一起使用，如 -fPIC -shared
• -fPIC，作用于编译阶段，告诉编译器产生与位置无关代码(Position-Independent Code)，  则产生的代码中，没有绝对地址，全部使用相对地址，故而代码可以被加载器加载到内存的任意位置，都可以正确的执行。这正是共享库所要求的，共享库被加载时，在内存的位置不是固定的
• -static，禁止使用共享链接
• -pipe，使用管道替代临时文件
• -g，生成调试信息

 

 

Mac下编译lua动态库，需要加上-dynamiclib -Wl,-undefined,dynamic_lookup，如编译ding.c，以下为Makefile里面文件内容:

linux:

#默认头文件头文件地址/usr/local/include

gcc ding.c -fPIC -shared -o ding.so

macosx:

gcc ding.c -fPIC -dynamiclib -Wl,-undefined,dynamic_lookup -shared -o ding.so -I/usr/local/include/lua

 

• 编译优化选项，O0 => O1 => O2 => O3开启的优化选项逐步加大，优化过的代码执行效率更佳，如kernel用O0是无法编译通过的，只能使用O2或Os
• -O2，基于运行速度优化
• -Os，基于目标生成文件size更小优化

　　　　　以上两者都能使部分函数自动inline。项目应该追求在O2的优化下能编译通过，如果在全局优化下，针对局部避免优化，可以尝试使用noinline 或 __attribute__((optimize(“O0”)))来修饰函数。