全局char数组引发GCC无错误信息返回1编译失败问题

• 核心错误是全局数组直接定义在了头文件中，没有做正确的符号处理
  你在kernel.h里直接写了全局作用域的char memory[MEMORY_SIZE];，所有引入这个头的.c文件，编译时都会生成一个同名的memory全局符号。
• 触发报错的直接原因是GCC 10版本的默认规则变更
  GCC 10之前默认开启-fcommon选项：未初始化的全局变量会被标记为弱公共符号，链接时多个同名弱符号会自动合并成一个，不会报重复定义错误。从GCC 10开始默认改为-fno-common，未初始化全局变量会作为强符号写入目标文件BSS段，多个同名强符号同时存在时，链接器直接抛出重定义错误并返回非0退出码，也就是你看到的make返回Error 1的现象。
• 为什么长度为1的数组能正常编译？
  这是GCC的兼容逻辑：长度为1的全局未初始化数组，即使在-fno-common模式下，仍会按旧的common弱符号规则处理，链接时自动合并，不会触发重定义。这就是为什么只有char memory[1];能通过编译，只要长度大于1就失败——和数组本身的大小上限没有任何关系，完全是符号合并规则导致的。
• 为什么看不到具体错误信息？
  你贴出来的所有输出全是编译阶段的警告，没有任何链接阶段的内容，说明你的makefile链接规则写得有问题：要么是把链接器ld的错误输出重定向丢弃了，要么是开了静默执行参数没打印链接阶段的报错，才会出现只有退出码、看不到错误详情的反常情况。
• 额外的隐患：你写的MEMORY_SIZE宏没有加括号，也没有做类型防溢出处理，后续如果在表达式中使用这个宏，很容易因为运算符优先级或者整型溢出触发莫名其妙的问题。

• 1. 按C语言的头文件规范分离声明和定义
     头文件中只放外部声明：在kernel.h里写extern char memory[];，然后在对应的一个.c文件（比如memory.c或者kernel.c）中写实际定义：char memory[MEMORY_SIZE];，保证整个程序中只有一个memory强符号，从根源上避免重定义问题。
• 2. 如果确实需要在头文件中定义数组，给数组加static修饰：static char memory[MEMORY_SIZE];，这样每个编译单元会生成自己私有的memory符号，不会和其他单元冲突。注意这种写法会让每个引入头的源文件都生成一份独立的数组，内存占用会成倍增加，内核开发场景下不推荐使用。
• 3. 修正makefile的链接规则，不要静默丢弃链接器的报错输出，后续遇到链接错误可以直接看到具体原因，不用盲猜排查。
• 4. 修正宏定义写法，所有数值宏用括号包裹，加无符号长整型后缀避免溢出：

#define MEMORY_GB 1
#define MEMORY_SIZE (100000UL * 1024UL * MEMORY_GB)

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