使用libc符号时是否需显式为程序/库链接libc（-lc）？

常规场景下不需要显式加-lc #

gcc、clang在执行链接操作时，默认会自动链接系统标准libc，不管是编译可执行程序还是共享库，普通场景下直接执行cc source.c -o output就能正常链接libc，完全不需要手动加-lc参数：

• 程序场景的Makefile里不需要加-lc配置，属于冗余配置
• 共享库对应的pkg-config文件的Libs字段也不需要加-lc，不会影响依赖该库的程序链接libc，加了反而可能在多重依赖时产生重复链接的冗余

完全不用libc符号时可选择不链接libc #

如果你的代码确实没有任何libc调用，且不需要依赖libc提供的程序入口（比如自己用汇编实现_start入口，直接通过系统调用访问内核能力），可以加-nostdlib编译参数关闭默认libc链接，不需要再链接libc，常用于制作最小化二进制、裸机程序等场景。

要注意一个坑：就算你代码里没有主动调用libc函数，编译器也可能自动生成依赖libc的代码，比如大结构体赋值时自动生成memcpy调用、栈保护逻辑自动生成__stack_chk_fail调用等，这种时候不链接libc会报符号未定义错误。

需要显式加/不加-lc的特殊场景 #

这些场景才会涉及显式操作libc链接的需求，也是你之前看到的推荐显式链接libc的适用场景：

• 直接用ld命令做链接而不是通过gcc/clang前端做链接：ld不会自动加默认的libc链接参数和启动文件，用到libc符号时必须手动加-lc，还要补充crt0.o等启动目标文件才能正常生成可执行程序
• 加了-nostdlib、-nodefaultlibs等关闭默认库链接的参数时，如果你还需要用到libc的能力，必须手动加-lc
• 有符号覆盖需求时：比如你要自定义某个libc函数（如malloc），需要手动调整-lc和自定义库的链接顺序，保证你的自定义符号优先级高于libc的符号
• 静态链接特殊依赖时：如果你的静态库依赖顺序比较特殊，出现libc符号未定义的报错，可以在依赖列表末尾显式加-lc解决顺序问题
• 交叉编译、使用非标准libc（如musl、uClibc）的场景：显式加-lc可以避免链接器找到错误版本的libc

内容的提问来源于stack exchange，提问作者alx - recommends codidact