centos 7 安装 oracle 11g 报 make 错误的根本原因是其构建脚本与新工具链不兼容：ins_emagent.mk 缺失 -lnnz11 导致链接失败，需手动追加；ins_ctx.mk 中 ctxhx 需静态链接 libc.a 并安装 glibc-static；同时 display 必须正确设置以避免 x11 转发中断。
CentOS 7 安装 Oracle 11g 报 make 错误，根本原因不是“编译器坏了”，而是 Oracle 11g 的构建脚本（尤其是 ins_emagent.mk 和 ins_ctx.mk）与 CentOS 7 的较新工具链（glibc ≥ 2.17、GCC ≥ 4.8、libstdc++ 版本演进）存在硬编码兼容性断层。它默认链接行为在旧系统上成立，在 CentOS 7 上直接失效。
ins_emagent.mk 中 $(MK_EMAGENT_NMECTL) 缺失 -lnnz11 导致链接失败
这是最常见报错，典型错误信息为：
Error in invoking target 'agentnmhs' of makefile '/oracle/product/11.2.0/db_1/sysman/lib/ins_emagent.mk'
本质是链接器找不到 libnnz11.so 符号，因为 Makefile 没告诉它去链接这个库。Oracle 11g R2 的安装程序在 CentOS 7 上不会自动推导该依赖。
- 必须以
oracle用户身份编辑：$ORACLE_HOME/sysman/lib/ins_emagent.mk - 搜索
MK_EMAGENT_NMECTL（注意大小写和下划线），定位到类似这一行：$(MK_EMAGENT_NMECTL) - 在该行末尾**紧贴空格后**追加：
-lnnz11（l 是小写 L，不是数字 1；11 是数字） - 修改前务必备份：
cp ins_emagent.mk ins_emagent.mk.bak - 保存后回到图形安装界面点 Retry，不要重启安装程序
ins_ctx.mk 中 ctxhx 链接失败：glibc 2.17+ 与 memcpy@GLIBC_2.14 不兼容
典型日志片段：
INFO: /lib64/libstdc++.so.5: undefined reference to `memcpy@GLIBC_2.14'
CentOS 7 自带 glibc 2.17，但 Oracle 11g 的 ctxhx 组件仍试图链接旧版符号。静态链接 libc.a 是绕过动态符号冲突的最稳定方式。
- 编辑：
$ORACLE_HOME/ctx/lib/ins_ctx.mk - 找到
ctxhx:开头的规则行（通常在几百行附近） - 将原行：
ctxhx: $(CTXHXOBJ) $(LINK_CTXHX) $(CTXHXOBJ) $(INSO_LINK) - 改为：
ctxhx: $(CTXHXOBJ) -static $(LINK_CTXHX) $(CTXHXOBJ) $(INSO_LINK) /usr/lib64/libc.a - 确保系统已安装
glibc-static：yum install -y glibc-static - 同样保存后点 Retry
DISPLAY not set 或 X11 转发失败导致 make 过程中断
很多人忽略：Oracle 图形安装器底层调用 make 时，会通过 X11 启动子进程（比如字体渲染、进度弹窗）。如果 DISPLAY 环境变量未正确设置或权限不足，make 会静默失败并退出，日志里只显示“target failed”，不报具体 X 错误。
- 绝对不要用
su - oracle切换用户 —— 这会丢失原始用户的 Xauthority 权限 - 必须用图形界面直接登录
oracle用户（或使用ssh -X连接并验证xauth list是否有有效 cookie） - 检查：
echo $DISPLAY应输出类似:0或localhost:10.0；xclock能正常弹窗才算通 - 若用 VNC，确认 VNC Server 启动时带了
-localhost no参数（否则拒绝本地 X 转发）
真正麻烦的不是改哪一行 Makefile，而是这些修改必须在安装程序卡住的那一刻立即完成，并且只对当前 session 生效 —— 下次重跑安装，又得重新改。所以建议把两个 .mk 文件的修复命令写成脚本，放在 $ORACLE_HOME 下备用。
