SQLAPI++：获取可执行文件加载的共享库的路径

Question

SQLAPI++有一个不寻常的特性，您可以设置一个字符串来告诉它在哪里可以找到。在我的例子中，这是libtdsodbc.so，我的应用程序实际上在构建时链接了这个库，但是在运行时，这还不足以使SQLAPI++工作。

我的代码是：

  SAConnection conn;
  conn.setOption("ODBC.LIBS") = "libtdsodbc.so";
  conn.Connect("SERVER=...", "", "", SA_ODBC_Client);

ODBC.LIBS是这样的记录在案：

强制SQLAPI++库使用指定的ODBC管理器库。

如果将LD_LIBRARY_PATH设置为包含libtdsodbc.so的目录，则上述代码可以工作。但如果你不这样做，Connect()就失败了：

libtdsodbc.so: cannot open shared object file: No such file or directory

DBMS API Library 'libtdsodbc.so' loading fails
This library is a part of DBMS client installation, not SQLAPI++
Make sure DBMS client is installed and
this required library is available for dynamic loading

Linux/Unix:
1) The directories in the user's LD_LIBRARY_PATH environment variable
2) The list of libraries cached in /etc/ld.so.cache
3) /usr/lib, followed by /lib

如果将ODBC.LIBS设置为完整路径(而不仅仅是文件名)，它将再次工作。但是，应用程序如何知道哪条路径？

我的应用程序(在SQLAPI++之外)通过其在构建时设置的RUNPATH找到libtdsodbc.so。此路径不是像/usr/lib那样的系统路径。我希望SQLAPI++使用在运行时加载到应用程序中的相同库。

一个想法是，对于RUNPATH的应用程序，搜索libtdsobc.so，并使用该路径。但这需要相当多细致的代码才能基本上重新实现ld.so已经完成的任务。

我不想在构建时将路径与RUNPATH分开烘焙到可执行文件中，因为我有时会在部署之前编辑RUNPATH (然后需要编辑两件事情)。

理想情况下，我想告诉SQLAPI++只使用已经加载的库。我可以通过运行lsof -p PID | grep libtdsodbc.so找到这条路径，但是在可执行文件中运行shell命令并不是一个好的解决方案(而且我还是不希望重新实现lsof)。

Answer 1

您可以使用phdr (链接还包括输出库名称的示例代码)或手动解析/proc/self/maps。