嘿，我来逐个拆解你的问题，都是Linux下C程序编译和链接的核心知识点：

1. 链接器是复制函数的内容，还是仅创建指向该函数的链接？ #

这取决于你用的是静态链接还是动态链接：

• 静态链接模式下：链接器会把函数的二进制代码直接复制到最终生成的可执行文件中，相当于把依赖的库代码完整打包进去，这样可执行文件是完全独立的，但体积会显著增大。
• 动态链接模式下：链接器不会复制函数的实际代码，只会在可执行文件中添加一个指向动态库中函数的引用标记。程序运行时，操作系统的动态链接器会负责加载对应的动态库，找到函数的实际内存地址后再执行。

2. 针对你的test.c代码的具体问题 #

先把你的代码贴出来方便参考：

#include <stdio.h>
int main() {
    printf("hi\n");
    return 0;
}

(1) 使用gcc test.c常规编译时，printf采用动态链接还是静态链接？ #

默认情况下，Linux上的GCC会对printf使用动态链接。因为系统默认提供的C标准库是动态库（比如libc.so.6），常规编译命令不会主动触发静态链接。如果要强制静态链接，需要添加-static参数，比如执行gcc -static test.c，这样链接器才会把C标准库中用到的代码打包进可执行文件。

(2) printf最终调用write()系统调用，链接器是复制printf到可执行文件，还是直接复制write()？转成ASCII后能看到哪个？ #

分两种情况看：

• 动态链接场景：可执行文件里既没有完整的printf代码，也不会有write的代码，只有对printf的动态引用记录。程序运行时，先加载libc.so动态库，找到printf的实现，然后printf内部会通过内核提供的接口触发write系统调用（这里的write是内核实现的服务，用户程序里只有触发调用的指令，没有write的代码）。
• 静态链接场景：链接器会把printf的完整实现代码复制到可执行文件中，但write作为系统调用，并不会被复制进来——因为系统调用是内核的功能，用户程序只是通过特定指令（比如syscall）请求内核执行write操作，不会包含write的代码。
• 用strings命令把可执行文件转成ASCII查看的话，你大概率能看到printf这个字符串（来自符号表或代码中的符号名），但很难直接看到write，因为printf调用的是libc封装后的系统调用入口，不会把write符号暴露到可执行文件的符号表中。

(3) 编译代码后卸载C标准库，程序还能运行吗？ #

还是分两种情况：

• 动态链接的程序：完全不能运行。程序启动时，操作系统的动态链接器（比如ld-linux.so）会先尝试加载依赖的libc.so库，如果这个库被卸载，动态链接器找不到依赖，会直接抛出错误，程序根本无法启动。
• 静态链接的程序：可以正常运行。因为静态链接已经把C标准库中用到的所有代码（包括printf的实现）都打包进了可执行文件，不需要依赖系统中的动态库。只要操作系统内核正常工作，程序就能独立运行。

内容的提问来源于stack exchange，提问作者Alex