看起来你遇到的问题是：明明配置了RPATH想让程序通过相对路径加载winter_fresh.so，但ldd输出却显示它用了绝对路径/home/projects/my_files/winter_fresh.so。这大概率是编译链接阶段的参数配置出了问题，下面给你拆解几个常见原因和验证方法：

1. 编译时直接指定了库的绝对路径 #

如果你的编译命令是类似这种写法：

gcc my_program.c /home/projects/my_files/winter_fresh.so -o my_program -Wl,-rpath='$ORIGIN/libs'

链接器会直接把你写的绝对路径硬编码进程序的动态依赖段里，完全不会触发RPATH的查找逻辑。正确的做法是用-L指定库的搜索目录，再用-l指定库名（去掉lib前缀和.so后缀）：

gcc my_program.c -L/home/projects/my_files -lwinter_fresh -o my_program -Wl,-rpath='$ORIGIN/libs'

这样链接器会先通过-L找到库，但只会把库名（或SONAME）写入程序，运行时就会通过你配置的RPATH去查找对应的库文件。

2. RPATH配置错误或未生效 #

你得先确认RPATH的路径是否正确指向了winter_fresh.so所在的相对位置。最常用的配置是用$ORIGIN指代程序自身所在的目录，比如如果库在程序同目录的libs文件夹里，编译参数应该写成：

-Wl,-rpath='$ORIGIN/libs'

这里的单引号一定要加！如果不加，shell会把$ORIGIN解析成空字符串，导致RPATH配置完全无效。你可以用readelf命令检查程序的动态段，确认RPATH/RUNPATH是否正确：

readelf -d my_program | grep -E '(RPATH|RUNPATH)'

如果输出的路径和你预期的不符，那就是RPATH没配置对，动态链接器自然会 fallback 到编译时的绝对路径。

3. 共享库未设置SONAME（次要原因） #

如果你的winter_fresh.so在编译时没有设置SONAME，链接器可能会把库的绝对路径写入程序，而不是仅记录库名。你可以在编译共享库时加上这个参数：

gcc -shared -fPIC winter_fresh.c -o winter_fresh.so -Wl,-soname,libwinter_fresh.so

设置SONAME后，链接器会把这个名称写入程序的依赖列表，运行时动态链接器就会通过RPATH查找匹配SONAME的库文件。

快速验证方法 #

用readelf查看程序的动态依赖字段：

readelf -d my_program | grep NEEDED

如果输出里是NEEDED /home/projects/my_files/winter_fresh.so，那就是第1种原因导致的；如果是NEEDED libwinter_fresh.so，那再重点检查RPATH的配置是否正确。

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