GCC和Makefile编译过程

gcc的使用方法

gcc [选项] 文件名
在这里插入图片描述
一个c/c++文件要经过预处理、编译、汇编和链接才能变成可执行文件。

  • (1)预处理
    C/C++源文件中,以#开头的命令被称为预处理命令,如"#include"、宏定义命令"#define"、条件编译命令"#if、#ifdef"等。预处理是将包含(include)的文件插入原文件中、将宏定义展开、根据条件编译命令选择要使用的代码,最后将这些东西输出到一个.i文件中并等待进一步处理。

  • (2)编译
    编译就是把C/C++代码(比如上述的.i文件)翻译成汇编代码。

  • (3)汇编
    汇编就是将第二步输出的汇编代码翻译成符合一定格式的机器代码,在Linux系统上一般表现为ELF目标文件(OBJ文件)。反汇编是指将机器代码转换为汇编代码,这在调试程序时常常用到。

  • (4)链接
    链接就是将上步生成的OBJ文件和系统库的OBJ文件、库文件链接起来,最终生成可以在特定平台运行的可执行文件。

hello.c(预处理) -> hello.i(编译) -> hello.s(汇编) -> hello.o(链接) -> hello
详细的每一步命令如下:
在这里插入图片描述
上面一连串命令有点多,gcc会对.c文件默认进行预处理操作,使用-c指明编译、汇编,从而得到.o文件, 再将.o文件进行链接,得到可执行应用程序。
简化的命令如下:
在这里插入图片描述
Makefile的引入及规则
Makefile要做什么事情呢? 组织管理程序和文件
文件a.c:

 #include <stdio.h>
  int main()
  {
    func_b();
    return 0;
  }

文件b.c:

#include <stdio.h>
 void func_b()
 {
      printf("This is B\n");
 }

编译:

gcc -o test a.c b.c

运行:

./test

结果:

This is B

gcc -o test a.c b.c这条命令虽然简单,但是它完成的功能不简单。

来看看它做了哪些事情。
我们知道.c程序 –> 得到可执行程序
要经过四个步骤:
1.预处理
2.编译
3.汇编
4.链接

我们经常把前三个步骤统称为编译。具体分析这条命令:gcc -o test a.c b.c
它们要经过下面几个步骤:
1).对于a.c执行:预处理 编译 汇编 的过程,a.c –>xxx.s –>xxx.o 文件。
2).对于b.c执行:预处理 编译 汇编 的过程,b.c –>yyy.s –>yyy.o 文件。
3).最后:xxx.o和yyy.o链接在一起得到一个test应用程序。

提示:gcc -o test a.c b.c -v :加上一个‘-v’选项可以看到它们的处理过程
第一次编译a.c得到xxx.o文件,这合乎情理, 执行完第一次之后,如果修改a.c ,又再次执行:gcc -o test a.c b.c,对于a.c应该重新生成xxx.o,但是对于b.c,又会重新编译一次,这完全没必要:b.c根本没有修改,直接使用第一次生成的yyy.o文件即可。
以上,不用Makefile的缺点:对所有的文件都会再处理一次,即使b.c没有经过修改,b.c也会被重新编译一次, 当文件比较少时,没什么问题,文件非常多的时候,编译的效率会很低。
如果文件非常多的时候,只是修改了一个文件,所有文件都会被重新编译一次,编译的时候就会需要很长时间。
对于这些源文件,我们应该分别处理,执行:预处理 编译 汇编 ,先分别编译它们,最后再把它们链接在一起比如:
编译:

gcc -o a.o a.c
gcc -o b.o b.c

链接:

gcc -o test a.o b.o  

比如:上面的例子,当我们修改a.c之后,a.c会重新编译, 然后再把它们链接在一起就可以,b.c 不需要重新编译。

问题又来了,怎么知道哪些文件被更新了/被修改了?

比较时间:比较a.o和a.c的时间,如果a.c的时间比a.o的时间更加新的话,就表明a.c被修改了。

同理,b.o和b.c也会进行同样的比较。比较test和a.o, b.o的时间,如果a.o或者b.o的时间比test更加新的话,就表明应该重新生成test。

Makefile 就是这样做的。
现在写出一个简单的Makefile:
makefie最基本的语法是规则,规则:
目标 : 依赖1 依赖2 …
[TAB]命令
当“依赖”比“目标”新,执行它们下面的命令。我们把上面三个命令写成makefile规则,如下:
test :a.o b.o //test是目标,它依赖于a.o b.o文件,一旦a.o或者b.o比test新的时候,需要执行下面的命令,重新生成test可执行程序。

gcc -o test a.o b.o

a.o : a.c //a.o依赖于a.c,当a.c更加新的话,执行下面的命令来生成a.o

gcc -c -o a.o a.c

b.o : b.c //b.o依赖于b.c,当b.c更加新的话,执行下面的命令来生成b.o

gcc -c -o b.o b.c

来做一个实验:
在该目录下写一个Makefile文件:
文件:Makefile

 test:a.o b.o
      gcc -o test a.o b.o
  
  a.o : a.c
     gcc -c -o a.o a.c
 
   b.o : b.c
      gcc -c -o b.o b.c

上面是makefile中的三条规则。makefile就是名字为“makefile”的文件。当我们编译程序时,直接执行make命令即可,一执行make命令它会生成第一个目标test可执行程序, 如果发现a.o 或者b.o没有,会先生成a.o或者b.o,发现a.o依赖a.c,有a.c但是没有a.o,它会认为a.c比a.o新,则执行它们下面的命令来生成a.o,同理,b.o和b.c的处理关系也是这样的。

如果修改a.c ,再次执行make,它的本意是想生成第一个目标test应用程序, 它需要先生成a.o, 发现a.o依赖a.c(假设我们修改了a.c),发现a.c比a.o更加新,就会执行gcc -c -o a.o a.c命令生成a.o文件。b.o依赖b.c,发现b.c并没有被修改,则不会执行gcc -c -o b.o b.c来重新生成b.o文件。

现在a.o b.o都有了,其中的a.o比test更加新,就会执行gcc -o test a.o b.o重新链接得到test可执行程序。所以当执行make命令,则会执行下面两条命令:

gcc -c -o a.o a.c
gcc -o test a.o b.o

第一次执行make的时候,会执行下面三条命令(三条命令都执行):

gcc -c -o a.o a.c
gcc -c -o b.o b.c
gcc -o test a.o b.o

再次执行make 会有下面的提示:
make: test is up to date.

再次执行make 会判断Makefile文件中的依赖,发现依赖没有更新,所以目标文件就不会重新生成,于是有上面的提示。当我们修改a.c后,重新执行make会执行下面两条指令:

gcc -c -o a.o a.c
gcc -o test a.o b.o

同时修改a.c b.c,执行make则会执行下面三条指令。

gcc -c -o a.o a.c
gcc -c -o b.o b.c
gcc -o test a.o b.o

a.c文件被修改了,重新编译生成a.o,
b.c被修改了,重新编译生成b.o,
a.o, b.o都更新了,则重新链接生成test可执行程序,makefile的规则其实不难
规则是Makefie的核心,执行make命令的时候,会在当前目录下找到名为:Makefile的文件,根据里面的内容来执行里面的判断/命令。
Makefile的语法
假如一个目标文件所依赖的依赖文件很多,我们岂不是要写很多规则?这显然不合乎常理。

我们可以使用通配符解决这些问题。我们对上节程序进行修改代码如下:

test: a.o b.o 
gcc -o test $^

%.o : %.c
gcc -c -o $@ $<

%.o:表示所用的.o文件

%.c:表示所有的.c文件

$@:表示目标

$<:表示第1个依赖文件

$^:表示所有依赖文件
在该目录下增加一个c.c文件,代码如下:

#include<stdio.h>
void func_c()
{
printf("This is C\n");
}

在main函数中调用修改的Makefile,修改后的代码如下:

test: a.o b.o c.o
gcc -o test $^
%.o : %.c
gcc -c -o $@ $<

执行:

make
结果:

gcc -c -o a.o a.c
gcc -c -o b.o b.c
gcc -c -o c.o c.c
gcc -o test a.o b.o c.o

运行:

./test

结果:

This is B
This is C
假想目标: .PHONY

1.我们若清除文件,在Makefile的结尾添加如下代码即可:

clean:
rm *.o test

1).执行make:生成第一个可执行文件。

2).执行make clean: 清除所有文件,即执行:rm *.o test。
2.使用Makefile

执行:make [目标]

也可以不跟目标名,若无目标默认第一个目标。执行make的时候,会在makefile里面找到第一个目标然后执行下面的指令生成第一个目标。当执行make clean的时候,会在Makefile里面找到clean这个目标,然后执行里面的命令,这个写法有些问题,原因是我们的目录里面没有clean这个文件,这个规则执行的条件成立,它就会执行下面的命令来删除文件。

如果:该目录下面有名为clean文件怎么办呢?

我们在该目录下创建一个名为“clean”的文件,然后重新执行make,make clean,结果(会有下面的提示:):

make: `clean’ is upto date.

它根本没有执行我们的删除操作,为什么?

我们之前说,一个规则能够执行的条件:

1).目标文件不存在

2).依赖文件比目标新。
现在我们的目录里面有名为“clean”的文件,目标文件是有的,并且没有依赖文件,没有办法判断依赖文件的时间。这种写法会导致:有同名的”clean”文件时,没有办法执行make clean操作。

解决办法:把目标定义为假想目标,用关键字PHONY

.PHONY: clean //把clean定义为假想目标。它便不会判断名为“clean”的文件是否存在, 然后在Makfile结尾添加.PHONY: clean语句,重新执行:make clean,就会执行删除操作。

假想目标: 变量

在makefile中有两种变量:

· 1)简单变量(即时变量):

A := xxx // A的值即刻确定,在定义时即确定

对于即时变量使用“:=”表示,它的值在定义的时候已被确定。

· 2)延时变量

B = xxx // B的值被使用到时才确定

对于延时变量使用“=”表示。它只有在使用到的时候才确定,在定义/等于时并没有确定下来。

想使用变量的时候使用“$”来引用,如果不想看到命令时,可以在命令的前面加上”@”符号,则不会显示命令本身。

当我们执行make命令的时候,make这个指令本身,会把整个Makefile读进去,进行全部分析,然后解析里面的变量。常用的变量的定义如下:
:= // 即时变量
= // 延时变量
?= // 延时变量, 如果是第一次定义才起效, 如果在前面该变量已定义则忽略这句

+= // 附加, 它是即时变量还是延时变量取决于前面的定义

?=: // 如果这个变量在前面已经被定义,这句话就不会起效果。
实例:

A := $(C)
B = $(C)
C = abc
 
#D = 100ask
D ?= weidongshan

all:

    @echo A = $(A)
    @echo B = $(B)
    @echo D = $(D)
    C += 123

执行:

make
结果:

A =
B = abc 123
D = weidongshan

分析:

  1. A := $©:A为即时变量,在定义时即确定,由于刚开始C的值为空,所以A的值也为空。

  2. B = ©:B为延时变量,只有使用到时它的值才确定,当执行make时,会解析Makefile里面的所用变量,所以先解析C=abc, 然后解析C+=123,此时C=abc123,
    当执行:@echoB=©:B为延时变量,只有使用到时它的值才确定,当执行make时,会解析Makefile里面的所用变量,所以先解析C=abc, 然后解析C+=123,此时,C=abc123,当执行:@echoB=(B) B的值为 abc 123。

  3. D ?= weidongshan:D变量在前面没有定义,所以D的值为weidongshan,如果在前面添加D = 100ask,最后D的值为100ask。

我们还可以通过命令行存入变量的值
例如执行:

make D=123456

里面的D ?= weidongshan这句话便不再起作用。

结果:

A =
B = abc 123
D = 123456

编译原理
源码要运行,必须先转成二进制的机器码。这是编译器的任务。
比如,下面这段源码(假定文件名叫做test.c):

#include <stdio.h>

int main(void){
  fputs("Hello, world!\n", stdout);
  return 0;
}

要先用编译器处理一下才能运行,编译步骤如下:

$ gcc test.c
$ ./a.out
Hello, world!

对于复杂的项目,编译过程还必须分成三步。

$ ./configure
$ make  
$ make install

第一步 配置(configure)

编译器在开始工作之前,需要知道当前的系统环境,比如标准库在哪里、软件的安装位置在哪里、需要安装哪些组件等等。这是因为不同计算机的系统环境不一样,通过指定编译参数,编译器就可以灵活适应环境,编译出各种环境都能运行的机器码。这个确定编译参数的步骤,就叫做"配置"(configure)。
这些配置信息保存在一个配置文件之中,约定俗成是一个叫做configure的脚本文件。通常它是由autoconf工具生成的。编译器通过运行这个脚本,获知编译参数。

configure脚本已经尽量考虑到不同系统的差异,并且对各种编译参数给出了默认值。如果用户的系统环境比较特别,或者有一些特定的需求,就需要手动向configure脚本提供编译参数:

$ ./configure --prefix=/www --with-mysql

上面代码是php源码的一种编译配置,用户指定安装后的文件保存在www目录,并且编译时加入mysql模块的支持。

第二步 确定标准库和头文件的位置

源码肯定会用到标准库函数(standard library)和头文件(header)。它们可以存放在系统的任意目录中,编译器实际上没办法自动检测它们的位置,只有通过配置文件才能知道。

编译的第二步,就是从配置文件中知道标准库和头文件的位置。一般来说,配置文件会给出一个清单,列出几个具体的目录。等到编译时,编译器就按顺序到这几个目录中,寻找目标。

第三步 确定依赖关系

对于大型项目来说,源码文件之间往往存在依赖关系,编译器需要确定编译的先后顺序。假定A文件依赖于B文件,编译器应该保证做到下面两点。
(1)只有在B文件编译完成后,才开始编译A文件。

(2)当B文件发生变化时,A文件会被重新编译。

编译顺序保存在一个叫做makefile的文件中,里面列出哪个文件先编译,哪个文件后编译。而makefile文件由configure脚本运行生成,这就是为什么编译时configure必须首先运行的原因。

在确定依赖关系的同时,编译器也确定了,编译时会用到哪些头文件。
第四步 头文件的预编译(precompilation)

不同的源码文件,可能引用同一个头文件(比如stdio.h)。编译的时候,头文件也必须一起编译。为了节省时间,编译器会在编译源码之前,先编译头文件。这保证了头文件只需编译一次,不必每次用到的时候,都重新编译了。

不过,并不是头文件的所有内容,都会被预编译。用来声明宏的#define命令,就不会被预编译。

第五步 预处理(Preprocessing)

预编译完成后,编译器就开始替换掉源码中bash的头文件和宏。以本文开头的那段源码为例,它包含头文件stdio.h,替换后的样子如下。

extern int fputs(const char *, FILE *);
extern FILE *stdout;

int main(void){

    fputs("Hello, world!\n", stdout);
    return 0;

}

为了便于阅读,上面代码只截取了头文件中与源码相关的那部分,即fputs和FILE的声明,省略了stdio.h的其他部分(因为它们非常长)。另外,上面代码的头文件没有经过预编译,而实际上,插入源码的是预编译后的结果。编译器在这一步还会移除注释。

这一步称为"预处理"(Preprocessing),因为完成之后,就要开始真正的处理了。
第六步 编译(Compilation)

预处理之后,编译器就开始生成机器码。对于某些编译器来说,还存在一个中间步骤,会先把源码转为汇编码(assembly),然后再把汇编码转为机器码。

下面是本文开头的那段源码转成的汇编码。

  .file   "test.c"
    .section    .rodata.LC0:
    .string "Hello, world!\n"
    .text    .globl  main    .type   main, @functionmain:.LFB0:
    .cfi_startproc
    pushq   %rbp    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp    .cfi_def_cfa_register 6
    movq    stdout(%rip), %rax
    movq    %rax, %rcx
    movl    $14, %edx
    movl    $1, %esi
    movl    $.LC0, %edi
    call    fwrite
    movl    $0, %eax
    popq    %rbp    .cfi_def_cfa 7, 8
    ret    .cfi_endproc.LFE0:
    .size   main, .-main    .ident  "GCC: (Debian 4.9.1-19) 4.9.1"
    .section    .note.GNU-stack,"",@progbits

这种转码后的文件称为对象文件(object file)。
第七步 连接(Linking)

对象文件还不能运行,必须进一步转成可执行文件。如果你仔细看上一步的转码结果,会发现其中引用了stdout函数和fwrite函数。也就是说,程序要正常运行,除了上面的代码以外,还必须有stdout和fwrite这两个函数的代码,它们是由C语言的标准库提供的。

编译器的下一步工作,就是把外部函数的代码(通常是后缀名为.lib和.a的文件),添加到可执行文件中。这就叫做连接(linking)。这种通过拷贝,将外部函数库添加到可执行文件的方式,叫做静态连接(static linking),后文会提到还有动态连接(dynamic linking)。

make命令的作用,就是从第四步头文件预编译开始,一直到做完这一步。
第八步 安装(Installation)

上一步的连接是在内存中进行的,即编译器在内存中生成了可执行文件。下一步,必须将可执行文件保存到用户事先指定的安装目录。

表面上,这一步很简单,就是将可执行文件(连带相关的数据文件)拷贝过去就行了。但是实际上,这一步还必须完成创建目录、保存文件、设置权限等步骤。这整个的保存过程就称为"安装"(Installation)。
第九步 操作系统连接

可执行文件安装后,必须以某种方式通知操作系统,让其知道可以使用这个程序了。比如,我们安装了一个文本阅读程序,往往希望双击txt文件,该程序就会自动运行。

这就要求在操作系统中,登记这个程序的元数据:文件名、文件描述、关联后缀名等等。Linux系统中,这些信息通常保存在/usr/share/applications目录下的.desktop文件中。另外,在Windows操作系统中,还需要在Start启动菜单中,建立一个快捷方式。

这些事情就叫做"操作系统连接"。make install命令,就用来完成"安装"和"操作系统连接"这两步。
第十步 生成安装包

写到这里,源码编译的整个过程就基本完成了。但是只有很少一部分用户,愿意耐着性子,从头到尾做一遍这个过程。事实上,如果你只有源码可以交给用户,他们会认定你是一个不友好的家伙。大部分用户要的是一个二进制的可执行程序,立刻就能运行。这就要求开发者,将上一步生成的可执行文件,做成可以分发的安装包。

所以,编译器还必须有生成安装包的功能。通常是将可执行文件(连带相关的数据文件),以某种目录结构,保存成压缩文件包,交给用户。
第十一步 动态连接(Dynamic linking)

正常情况下,到这一步,程序已经可以运行了。至于运行期间(runtime)发生的事情,与编译器一概无关。但是,开发者可以在编译阶段选择可执行文件连接外部函数库的方式,到底是静态连接(编译时连接),还是动态连接(运行时连接)。所以,最后还要提一下,什么叫做动态连接。

前面已经说过,静态连接就是把外部函数库,拷贝到可执行文件中。这样做的好处是,适用范围比较广,不用担心用户机器缺少某个库文件;缺点是安装包会比较大,而且多个应用程序之间,无法共享库文件。

动态连接的做法正好相反,外部函数库不进入安装包,只在运行时动态引用。好处是安装包会比较小,多个应用程序可以共享库文件;缺点是用户必须事先安装好库文件,而且版本和安装位置都必须符合要求,否则就不能正常运行。

现实中,大部分软件采用动态连接,共享库文件。这种动态共享的库文件,Linux平台是后缀名为.so的文件,Windows平台是.dll文件,Mac平台是.dylib文件。
参考文章:
gcc&arm-linux-gcc编译过程详解
Makefile的引入及规则
Makefile的语法

©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页
实付 19.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值