Linux下lib与lib64按架构区分，编译安装需主动指定路径：configure用--with-xxx或CFLAGS/LDFLAGS指向/include和/lib64，链接时嵌入-Wl,-rpath，运行时通过/etc/ld.so.conf.d/和ldconfig注册lib64路径。
Linux 下 lib 与 lib64 的区分源于系统架构（32 位用 lib，64 位主流用 lib64），但编译安装软件时，不能靠“猜路径”，而要主动告诉构建系统该去哪找头文件和动态库——尤其是当 OpenSSL、zlib 等依赖被装在 /opt/openssl 或 /usr/local 这类非标准位置时。
configure 阶段：明确指定 lib 和 lib64 所在路径
大多数 GNU Autotools 项目（如 Nginx、Redis、FFmpeg）通过 ./configure 脚本解析依赖。若你的库装在 /opt/openssl，它通常结构为：
-
/opt/openssl/include/→ 头文件（.h） -
/opt/openssl/lib/→ 动态库（libssl.so.1.1） -
/opt/openssl/lib64/→ 某些发行版或自定义编译会把 64 位库放这里（如 CentOS/RHEL 风格）
这时需显式传参，避免 configure 自动扫描失败：
- 用
--with-openssl=/opt/openssl告诉它前缀，configure 会默认查include/和lib/ - 若实际库在
lib64/，加CFLAGS="-I/opt/openssl/include" LDFLAGS="-L/opt/openssl/lib64"强制指定 - 更稳妥的是用链接器参数嵌入运行时路径：
--with-ld-opt="-L/opt/openssl/lib64 -Wl,-rpath,/opt/openssl/lib64"
make 阶段：确认链接器是否真正用了你指定的 lib64
执行 make 前，可临时导出环境变量辅助验证：
-
export LIBRARY_PATH="/opt/openssl/lib64:$LIBRARY_PATH"（影响编译期链接） -
export PKG_CONFIG_PATH="/opt/openssl/lib64/pkgconfig"（若依赖提供 .pc 文件）
编译完成后，用 ldd src/nginx（以 Nginx 为例）检查是否链接到了你预期的库：
- 看到
libssl.so.1.1 => /opt/openssl/lib64/libssl.so.1.1→ 成功 - 看到
libssl.so.1.1 => /lib64/libssl.so.1.1→ 仍连了系统库，说明 configure 或 LDFLAGS 没生效
install 后：让系统运行时能定位 lib64 中的库
即使编译链接正确，运行时仍可能报 error while loading shared libraries。这是因为系统默认只查 /lib 和 /usr/lib（/usr/lib64 在部分系统中自动包含，但 /opt/xxx/lib64 不在其中）：
- 推荐做法：新建
/etc/ld.so.conf.d/openssl-lib64.conf，写入一行/opt/openssl/lib64，再执行sudo ldconfig - 验证是否生效：
sudo ldconfig -v 2>&1 | grep openssl应显示扫描到该路径 - 不建议用
LD_LIBRARY_PATH部署服务，systemd、crond 等会忽略它；仅调试时临时使用
特殊情况处理：lib 与 lib64 并存或混用
有些软件包（如某些 Intel MKL 或自编译 OpenSSL）会同时生成 lib/ 和 lib64/，且内容不同（例如 lib64 含 ABI 特定优化版本）。此时：
- 不要软链
lib64 → lib，可能导致 ABI 冲突 - configure 时分别指定：
LDFLAGS="-L/opt/mkl/lib64 -L/opt/mkl/lib" - 运行时路径也需都加入
ld.so.conf.d/，每行一个路径 - 用
readelf -d ./your_binary | grep RUNPATH查看二进制内嵌的 rpath 是否覆盖全部所需目录
