纯64位Linux From Scratch（LFS）为何无法将lib64设为默认库目录

第一遍编译GCC时-m64路径配置问题 #

你看到的case语句将-m64对应目录改为../lib而非lib64，是临时工具链隔离设计的要求：
第一阶段编译的GCC属于临时工具链组件，仅用于构建后续目标系统的glibc和最终版GCC，不会保留到最终LFS系统中。该配置的核心作用是强制临时GCC优先链接$LFS/tools目录下的临时库，完全规避调用宿主系统/lib64或/usr/lib64下的库文件。如果改为../lib64，临时GCC会优先从宿主系统的lib64目录查找依赖，极易出现宿主库和临时工具链版本不兼容的编译错误，不符合临时工具链完全与宿主隔离的设计原则。

glibc路径相关配置疑问 #

你观察到的ldd补丁修改硬编码路径为/lib、同时编译配置将默认库目录设为/usr/lib的设计，确实是遵循Fedora usr/move规范的实现：

• 系统引导阶段，内核和initramfs仅能访问根分区下的目录，将动态加载器、系统启动必需的核心库存放在/lib目录下，可保证/usr分区未挂载时系统仍能正常启动
• 编译配置将默认库目录设为/usr/lib是现代发行版的统一设计，后续用户安装的所有软件包、第三方库都会默认存放在该目录，/lib和/usr/lib通过符号链接做兼容，不存在路径冲突问题

纯64位LFS不使用lib64目录的核心原因 #

• 默认纯64位LFS没有兼容32位程序的需求，不需要用lib和lib64区分不同架构的库文件，统一使用lib目录存放所有64位库可以简化目录结构，避免多架构路径配置带来的冗余
• 纯64位模式下编译的glibc仅会生成64位库文件，不存在自带32位库的情况
• BLFS中的32位legacy程序属于可选扩展需求，默认LFS基础系统不默认支持32位程序运行。如果需要多架构支持，LFS官方提供了专门的CLFS（Cross Linux From Scratch）分支方案，会使用lib64、lib32等多架构目录，和默认单架构LFS方案相互独立
• 部分发行版使用lib64目录的核心目的是同时兼容32位和64位程序，单架构场景下没有使用lib64的必要性，LFS的设计选择优先保证基础系统的简洁性，把多架构支持作为可选扩展而非默认配置

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