简介

glibc（GNU C Library）是Linux采用的C语言运行库，它提供了ISO C11/POSIX.1-2008等标准定义的一系列API，几乎被所有应用所引用。阅读其源码能够提升对计算机底层组件的认知层次，修炼内功。

不同于python这类解释型语言可以直接在解释器中运行程序，C作为编译型语言需要将源码编译链接成机器码后才能执行（关于编译链接的具体机制可以参看我之前写的介绍文章：理解C语言-3:编译链接）。在glibc这样的超大型项目中，编译过程尤为复杂：不仅需要考虑不同平台间的不同配置项，还需要通过awk/sed等文本处理程序生成各种项目依赖文件。如果贸然扎进源码分析某个模块，很容易陷入不知道某个具体符号来自哪里的困境，铩羽而归。

GNU Make负责完成如此负责的编译，本文就通过分析Make的调试信息，解析编译glibc的具体过程，引出glibc源代码的目录结构，为后续分析glibc中的具体模块打下基础。

简介

上一篇介绍了C语言如何通过语句操作数据。本篇依旧贯彻解决”为什么”的原则，以终为始，从操作系统执行程序所需的内存布局入手，反推在源代码和最终可执行文件之间，编译和链接子系统需要做哪些工作。

简介

上一篇主要描述了C语言如何将待处理的数据建模成变量。有了变量，接下来需要拆解的就是如何使用他们。

初衷

市面上介绍C语言的书很多，但是大都是从语法和实践入手，以传授”怎么做”或者”怎么做好”为根本目标。俗话说授人以鱼不如授人以渔，虽然我不是C语言的设计者，但是却渴望从”为什么”切入，顺藤摸瓜理顺C语言为什么长成这样。

其次，C语言是现代计算机语言的鼻祖，也是绝大多数高级语言编译器或解释器的实现语言，理解C的设计理念，对于学习各类现代高级语言一定会有所帮助。

废话不多，让我们从内存数据对象入手拆解C语言吧。