Linux编程之gcc g++ gdb 零基础入门 Linux C C++ 编译器 调试器

很多人写 C/C++ 卡住的地方，不是语法，而是"代码写完，然后呢"。在 Linux 下敲下 gcc hello.c 之后屏幕安静地回到提示符，什么都没发生，也不知道是编译失败还是自己忘了运行；程序跑起来结果不对，只能靠加 printf 到处打印，改一轮、编一轮、猜一轮。这门课要补的就是这段缺口——把编译和调试这两件"必须会、但大多数人是靠试出来"的事讲成可复用的方法。

先确认你是不是缺这块

下面这些情况如果中了三条以上，这门课对你就是对症的：

• 分不清 gcc 和 g++ 的差别，写 C++ 时随手用 gcc，遇到链接错误只能靠搜索引擎碰运气。
• 编译报错看得懂单个词，但看不懂一串 undefined reference，不知道是缺头文件、缺库还是链接顺序问题。
• 知道要加 -g 才能调试，但不知道为什么加、不加会怎样。
• 听说过断点、单步、调用栈，实际操作时只会 printf 大法，程序一崩就重跑。
• 对段错误（Segmentation fault）只有恐惧，没有定位手段。
• 写过多文件项目，但每次都是把文件全列在命令行里，没碰过 Makefile。

如果这些你都熟练，那这门课偏基础，可以跳过。

编译这条线要理清什么

gcc 和 g++ 的名字容易让人以为是两个独立的编译器，实际上它们来自同一个套件，差别主要在默认行为和链接的库上。课程会把预处理、编译、汇编、链接这四个阶段拆开看，理解之后你就能明白：为什么头文件找不到是预处理阶段的问题，为什么符号未定义是链接阶段的问题，为什么加了 -c 就只生成目标文件。

围绕这一步，需要练的是几组常见编译选项的用法——指定头文件搜索路径、指定库路径、链接某个具体库，以及理解为什么库的书写顺序会影响链接结果。这些不是背下来就完事的，动手改一次错误顺序、看一次报错，比读十遍说明有用。

调试这条线要建立什么习惯

gdb 的门槛不在命令多，而在于要先有一份带调试信息的可执行文件。课程会从编译时加调试选项讲起，再进入实际的操作：怎么在某个函数或某一行停下，怎么看当前变量的值，怎么一层层往上翻调用栈找到是谁把参数传错的。

更值得练的是两个高频场景：一是程序崩溃后拿到核心转储，怎么还原出事现场；二是设条件断点，让程序只在特定输入下停下来，避免在循环里单步几百次。这两招学会之后，调试时间会明显下降。

同时也要知道 gdb 不是万能药。有些错误（比如内存越界、使用未初始化内存）光靠断点看不出来，需要配合其他手段，课程会说明边界在哪，避免你在错误方向上死磕。

看完应该能回答的问题

• gcc 和 g++ 编译同一个 .cpp 文件，结果有什么不同，为什么。
• 一个 undefined reference 报错，你会按什么顺序排查。
• 把库文件写在命令行的位置调换一下，为什么有时能编过、有时编不过。
• 程序段错误了，从启动 gdb 到定位到出错行，中间要经过哪几步。
• 什么情况下条件断点比普通断点省事。
• 一个由多个源文件组成的项目，从手写编译命令过渡到 Makefile，解决的到底是什么重复劳动。

怎么用这门课

建议是边看边敲，不要只看不动手。每学一个编译选项，就故意写错一次，看报错长什么样；每学一条调试命令，就在一段自己写的、有 bug 的代码上试一遍。零基础不等于可以只看不练，编译和调试本身就是手熟的过程，看会了和用会了之间差着一整轮练习。

如果时间紧，可以按这个优先级：先解决"编译能过、程序能跑"，再解决"跑错了能查"，最后再看多文件组织和构建工具。这样每一步都有能立刻用上的产出，不至于学完还不知道明天该怎么写代码。