SQLAPI ++에는 ODBC 공유 라이브러리를 찾을 위치를 지정하는 문자열을 설정하는 특이한 기능이 있습니다. 내 경우에 이것은 libtdsodbc.so이고 내 응용 프로그램은 실제로 빌드시에 라이브러리를 링크하지만 런타임에는 SQLAPI ++가 작동하기에 충분하지 않습니다.SQLAPI ++ : 실행 파일로로드 된 공유 라이브러리의 경로 가져 오기
부대 SQLAPI ++ 라이브러리 ODBC 관리자 라이브러리를 지정 사용하려면 :
SAConnection conn; conn.setOption("ODBC.LIBS") = "libtdsodbc.so"; conn.Connect("SERVER=...", "", "", SA_ODBC_Client);
ODBC.LIBS이 같은 documented입니다 :내 코드입니다. 당신이
libtdsodbc.so를 포함하는 디렉토리로LD_LIBRARY_PATH를 설정하면
위의 코드
작동합니다. 당신이하지 않는 경우에,Connect() 실패 : 당신은 그냥 파일 이름이 아닌 전체 경로로
ODBC.LIBS를 설정하면
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
다시 작동합니다. 그러나 애플리케이션이 어떤 경로를 알 수 있습니까?
내 응용 프로그램 (SQLAPI ++ 외부)은 빌드시 설정할 RUNPATH을 통해 libtdsodbc.so을 찾습니다. 이 경로는 /usr/lib과 같은 시스템 경로가 아닙니다. SQLAPI ++에서 런타임에 응용 프로그램에로드되는 동일한 라이브러리를 사용하고 싶습니다.
하나의 아이디어는 inspect its own RUNPATH으로, libtdsobc.so으로 검색하고 해당 경로를 사용하는 것이 좋습니다. 그러나 이것은 실질적으로 ld.so이 수행하는 코드를 다시 구현하기 위해 까다로운 코드를 필요로합니다.
배포하기 전에 RUNPATH을 편집 할 때 가끔 RUNPATH을 편집하기 때문에 빌드 할 때 실행 파일에 경로를 별도로 굽지 않으려합니다 (두 가지를 편집해야합니다).
SQLAPI ++에 이미로드 된 라이브러리 만 사용하는 것이 이상적입니다. lsof -p PID | grep libtdsodbc.so을 실행하여이 경로를 파악할 수 있지만 실행 파일에서 셸 명령을 실행하는 것은 좋은 해결책이 아닙니다. 다시 말해서 lsof을 다시 구현하지는 않을 것입니다.