记一次rpath的问题在debian上的分析

一个服务器新装了debian系统，体验一下。

编译安装一个php8.2，发现安装出错，还是libiconv的老问题。能找到libiconv，但是版本支持errno。

libiconv的早期版本的确不支持errno。

编译安装了最新版的libiconv 再次尝试编译php，仍然报错。

奇怪了，php的安装脚本使用了很长时间，怎么就这次有问题。尝试研究一下。

按报错信息看，确实可以找到libiconv，但是不支持errno。

查看configure日志，发现可以找到libiconv，但是在对errno执行检测时，运行的AC_SOURCE的c语言代码，编译是成功的。

但是执行起来却报错 找不到 libiconv.so.2。

那么编一些c代码试试，通过gcc编译后，执行确实找不到。这里就引出了rpath。

一般程序执行找so 无非是按照默认路径搜索，这是如果指定环境变量 LD_LIBRARY_PATH 到libiconv/lib 是可以执行的。

再一种方式就是编译时 指定rpath,指定好之后也就不用再设置环境变量了。

readelf -d a.out 

可以查看是否有rpath或者runpath 

再次检查php的编译脚本，发现编译参数中--disable-rpath 关闭了rpath的设置。却掉这个参数项，编译成功。

那么回到之前系统正常编译安装php的机器上查看。php 实际执行时用的so，并不是手动安装libiconv，而是系统自带的，可能是安装某个软件，依赖安装了libiconv。这样也就没有设置rpath的情况下，在默认的搜索路径总找到了动态链接的so。