oracle 11g静默安装报“ld: cannot find libpthread_nonshared.a”是因现代linux缺glibc-static包，需yum install glibc-static libstdc++-static -y，并确保compat-libstdc++-33、libaio-devel等关键依赖已安装。
ld: cannot find libpthread_nonshared.a 是链接器找不到系统库
这不是 oracle 安装脚本本身的问题，而是 ld（gnu linker）在编译 oracle 自带的 c 模块时，明确要求链接 libpthread_nonshared.a 这个静态归档文件，但现代 linux 发行版（如 centos 7、fedora 13+、ubuntu 16.04+）已不再默认安装它，也不再将其放在 /usr/lib/ 下。
常见错误现象包括：
/usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a-
make: *** [ctxhx] Error 1（出现在ins_ctx.mk构建阶段） - 后续连锁报错如
cannot find libc_nonshared.a、libgcc_s.so.1等
根本原因不是没装 gcc，而是缺开发用的“静态链接支持包”。只装 gcc 和 glibc 不够——你需要的是 glibc-static 和 libstdc++-static（或对应发行版的等效包）。
实操建议：
- CentOS/RHEL 7+：运行
yum install glibc-static libstdc++-static -y - Ubuntu/Debian：运行
apt-get install libc6-dev libstdc++-dev -y（它会自动拉取libpthread_nonshared.a所在的libc6-dev包） - 若仍报错且
find /usr -name 'libpthread_nonshared.a' 2>/dev/null无结果，再考虑软链方案（见下一条）
为什么软链 /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a 能临时绕过？
因为 Oracle 的 makefile 硬编码搜索路径是 /usr/lib/，而新系统把这类静态库移到了架构子目录（如 /usr/lib/x86_64-linux-gnu/）。软链只是让 ld “以为”它在老位置。
但要注意：
- 必须确认你的系统架构：用
uname -m查，x86_64对应 64 位，i686或i386对应 32 位；路径里写错会导致软链无效 - 软链目标文件必须真实存在，否则
ln -s成功但链接仍失败；先find /usr/lib* -name libpthread_nonshared.a确认位置 - 典型需软链的文件不止一个：
libc_nonshared.a、libgcc_s.so.1、libstdc++.so.6，漏掉任一都可能在下一个make目标中断 - 软链是权宜之计，重启安装前务必
rm -f /usr/lib/libpthread_nonshared.a并重装glibc-static，避免污染系统
安装 gcc 及开发套件包时容易忽略的关键点
很多人执行 yum groupinstall "Development Tools" 就以为万事大吉，但 Oracle 11g 实际依赖更细粒度的包。这个组不包含 glibc-static，也不保证 libaio-devel、unixODBC-devel 等被拉入。
必须显式安装的最小集合（以 CentOS 7 为例）：
-
gcc、gcc-c++（C/C++ 编译器） -
glibc-devel、glibc-static（头文件 + 静态库，libpthread_nonshared.a就在这里） -
libaio、libaio-devel（异步 I/O 支持，Oracle 启动必需） -
compat-libstdc++-33（Oracle 11g 二进制仍依赖旧 ABI，不装会报undefined reference to `memcpy@GLIBC_2.14'） -
binutils、make、sysstat（构建与监控工具）
验证是否装全：运行 rpm -q gcc gcc-c++ glibc-static libaio-devel compat-libstdc++-33，输出应全是包版本号，无 package xxx is not installed。
报错 C [ld-linux-x86-64.so.2+0x14d70] 的真实含义
这不是 Oracle 的错误，而是 ld-linux-x86-64.so.2（动态链接器）在加载某个共享库时发生段错误（SIGSEGV），地址偏移 +0x14d70 表示它在解析符号或重定位时崩溃。这通常发生在：
- 你强行用
LD_PRELOAD注入了不兼容的.so（比如错误版本的libstdc++.so.5） - 系统
glibc版本过高（如 CentOS 7 的 glibc 2.17），而 Oracle 11g 的某些组件（如ctxhx）是用旧版工具链编译的，无法处理新 glibc 的符号版本机制 - 硬塞了错误的
libstdc++.so.5（比如从 CentOS 5 拷来的），导致 ABI 冲突
此时别碰 ld-linux 本身——它不可改。正确做法是：
- 优先用
glibc-static+ 正确compat-libstdc++-33组合，避免运行时链接冲突 - 若必须降级，只替换 Oracle 安装目录下的
$ORACLE_HOME/lib/libstdc++.so.5，不要动系统全局的/usr/lib64/libstdc++.so.5 - 静默安装前加环境变量：
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib64:/usr/lib64，确保 Oracle 自带库优先于系统库被加载
实际安装中，最常被跳过的其实是 glibc-static 和 compat-libstdc++-33 这两个包；它们不参与常规开发，却直接决定 Oracle 11g 的 make 阶段能否走完。
