一文解决C程序的编译问题

对于C源码编译,大部分人都停留在./configure --prefix=XXX && make && make install这一步,大部分的程序都能顺利走完这一步,然后被安装到指定的文件下,小部分的程序会因为xxx不全而出错,然后你把这个问题放到搜索引擎上,就会找到一篇博客说用sudo apt-get/yum install xxx 后可以解决问题,然后问题解决了。因此从某种意义上来说编译不应该构成问题,直到你没有了root权限,直到了你开始管理服务器,不能随心所欲的用管理员权限安装程序,问题才出现了。

第一个问题是服务器的GCC版本过低,但不能随便升级,只能另起炉灶通过旧版本编译出新的GCC安装到类似于/opt,/local/usr或者是家目录下。我一般就用如下代码

cd ~/src
wget https://mirrors.tuna.tsinghua.edu.cn/gnu/gcc/gcc-7.2.0/gcc-7.2.0.tar.gz
tar xf gcc-7.2.0.tar.gz
cd gcc-7.2.0
./contrib/download_prerequisites
mkdir build && cd build
../configure --prefix=$HOME/opt/sysoft/gcc-7.2.0 --disable-multilib --enable-threads=posix
make -j 8 && make install

将编译好的gcc添加到环境变量中基本上就行了,基本上都没有遇到问题。所以如果你出错了,欢迎联系我,让我见识一下错误。

解决这个问题之后,让我们深入了解一下./configure && make && make install到底是做了那些事情。

众所周知,Linux的发行版是非常多的,那么代码开发的机器和实际运行的机器有很大概率是不同的,为了保证编译能通过,必须先要检查实际运行的机器是否符合要求。configure的首要目的就是检查依赖的头文件函数库在目标机器上是否存在,如果存在则万事大吉,可以愉快的make && make install,如果不存在就得用到configure第二个功能,调整编译行为。当你用./configure --help时,就会出现一些输出,大致分为如下几类:

  • 修改安装路径,如--prefix
  • 调整安装目录,在--prefix=PREFIX的前提下,可以调整其中的lib,include, share等文件的位置
  • 指定依赖工具的安装地址
  • 影响编译行为的环境变量

其中最后一类的环境变量非常重要,因为它可以通过改变gcc参数影响到编译的不同阶段。这个时候,就得需要了解编译到底分为几个阶段了, 需要几个简单的例子说明.

我们都写过也编译过最简单的C程序,功能就是从屏幕上输出"hello world!", 将如下代码保存为"hello.c"

#include <stdio.h>

int main(){
    printf("hello world!\n");
    return 0;
}

之后使用gcc -o hello hello.c就生成了可以执行的hello,虽然简单,但其实gcc做的任务不少. 它首先得在 预处理,编译,汇编 这一步找头文件"stdio.h", 默认查找路径是/usr/include, /usr/local/include, 如果这两个地方都没有找到,并且没有提供额外路径,那么它就会报错,比如我添加了一个默认路径没有的头文件,zlib.h,那么它就会报错,尽管系统里就有这一个文件。

#include <stdio.h>
#include <zlib.h>
int main(){
    printf("hello world!\n");
    return 0;
}
# error
hello.c:2:19: fatal error: zlib.h: No such file or directory
 # include <zlib.h>
                   ^
compilation terminated.

那么如何解决呢?第一种方法就是提供绝对路径,即</path/to/zlib.h>, 但是既不美观,也不好迁移到其他环境; 第二种方法就是告诉gcc可以去哪些地方查找头文件,这个参数就是 -I/path/to/where, 那么最终编译代码就是gcc -I/cluster/zlib-1.2.11/include/ -o hello hello.c. 大部分configure都允许你使用"CPPFLAGS","CFLAGS"增加头文件所在路径,这两个环境变量和类似的"CXXFLAGS"基本是等价关系,因为Makefile的语法都是$(CC) $(CPPFLAGS) $(CFLAGS) example.c -c -o example.o.

对于一个大项目而言,通常是不会把代码放在一个文件里,而是有多个文件组成,比如说现在有两个c文件

主函数:hello.c
# include <stdio.h>
int main(){
    printf("hello world!\n");
    reply();
    return 0;
}

次函数: reply.c
#include <stdio.h>
void reply(){
    printf("hi!\n");
}

那么为了编译出最终的程序,就需要分别编译然后调用ld进行链接,最终才能得到可执行的文件

gcc -c hello.c reply.c
gcc -o hello hello.o  reply.o

这种项目内先生成目标文件(.o)然后进行链接的编译行为其实不会对我们编译软件造成影响,对我们造成影响的是这个程序还用到了其他项目的函数库的时候,也就是需要其他项目的xxx.so文件。正如R语言我们用到最多的调用别人的R包,我们如果想用C计算sin(3.14/2),应该不会想到动手写一个三角函数, 我们会去调用已有的函数。继续以之前hello.c 和 reply.c 为例,这不过别人已经编译了一个动态函数库libreply.so给我们调用。

gcc -shared -fPIC  -c reply.c
gcc -shared -fPIC -o libreply.so reply.o

当我们直接编译hello.c时候,不会通过链接这一步,因为我们的libreply.so并不在默认的搜索路径中

$ gcc -o hello reply.c
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

为了编译能够通过,就需要用-L-l参数,第一个增加动态函数库搜索路径,第二个函数库的名字,也就是去掉"lib"和".so"剩下的部分。

gcc -o hello hello.c -L. -lreply

编译的确通过了,但是./hello运行的时候却会报错,而且这个错误我们可能非常的眼熟。

./hello
./hello: error while loading shared libraries: libreply.so: cannot open shared object file: No such file or directory
# 使用ldd检查动态库情况
$ ldd hello
    linux-vdso.so.1 =>  (0x00007ffc0a75f000)
    libreply.so => not found
    libc.so.6 => /lib64/libc.so.6 (0x00007f6224d36000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f622510f000)

为什么会出现这个情况?这是因为动态函数库的使用分为两个情况,首先是编译的时候会用到,然后是具体执行的时候也会用到。因此,尽管我们通过了编译,但是由于libreply.so并不在系统的动态函数库搜索路径中(可以通过ldconfig -p 和 cat /etc/ld.so.conf查看),那么它依旧会因为找不到而出错。第一种解决方法是利用LD_LIBRARY_PATH增加动态库运行时路径,这个和configure无关。

export LD_LIBRARY_PATH="$HOME/temp:LD_LIBRARY_PATH"
./hello

这样做看似解决了问题,但其实会造成更大的隐患,你可以尝试一下编译glibc,然后把glibc的lib添加到LD_LIBRARY_PATH中,你就遇到神奇的核心已转移问题。这就是动态函数库冲突的结果,所以更好的而解决方法是用gcc的Wl,-R/path/to/where参数控制ld的链接行为,软连接到所需动态库上,既可以是绝对路径,也可以是相对路径。你可以用ldd去看看bioconda安装的程序的动态库位置。

gcc -L. -lreply -Wl,-R./ hello.c -o hello
$ ldd hello
    linux-vdso.so.1 =>  (0x00007ffe6cb11000)
    libreply.so => ./libreply.so (0x00007fd7609e8000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fd76060d000)
    /lib64/ld-linux-x86-64.so.2 (0x000055fb9fc84000)

./configure和动态库相关的环境变量就是 LDFLAGS, 可以用export LDFLAGS=-L/path/to/lib -Wl,-R/paht/to/lib调整行为。

总结一下:使用./configure && make && make install编译程序的而时候,如果遇到出错,基本上就是头文件和动态库找不到,可以通过CFLAGS/CXXFLAGS/CPPFLAGS增加头文件路径,LDFLAGS增加动态库编译和搜索时的路径。不太推荐使用LD_LIBRARY_PATH, 会导致核心已转移。 如果程序安装说明里面没有./configure这一步,那么可以修改对应Makefile里的变量来解决出错。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,324评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,356评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,328评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,147评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,160评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,115评论 1 296
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,025评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,867评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,307评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,528评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,688评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,409评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,001评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,657评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,811评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,685评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,573评论 2 353

推荐阅读更多精彩内容