我有SCons代码，我使用SConscripts分别构建不同的目录。在我的Src目录中，我的SConscript构建了一个共享库，然后将生成的Node作为Python变量libMyLibrary返回。我通常使用install选项将此库复制到系统LD_LIBRARY_PATH上的目录（我使用的是OpenSUSE）。
到目前为止，这么好。现在，在另一个目录Src/Test中，另一个SConscript导入libMyLibrary并使用以下代码构建一些程序：
env.Program('myProgram', 'myProgram.cpp', LIBS=[env['LIBS'], libMyLibrary])
然后程序安装到我的本地bin文件夹。此代码确实跟踪库依赖项并构建程序，但问题是由于库位于子目录（Src）中，该子目录包含在链接器命令中。以下是SCons生成的链接器命令的缩写示例：
g++ -o Src/Test/myProgram Src/Test/myProgram.o Src/libMyLibrary.so
我相信这是因为节点libMyLibrary本质上是一条路径。问题是，当我尝试运行程序时，它不是在我的库文件夹中查找libMyLibrary.so，而是Src/libMyLibrary.so，当然它找不到它。
我不希望我构建的库安装在我的安装文件夹的子目录中。
我已将Src文件夹添加到LIBPATH，因此SCons将-LSrc选项添加到链接器命令，但这并不能解决问题。我的偏好是，当我添加一个Node时，应该自动解析该路径以添加适当的-L和-l选项。
我知道我可以通过将字符串'MyLibrary'添加到LIBS变量而不是libMyLibrary节点来解决此问题，但是我必须明确告诉SCons每个程序Depends()上的libMyLibrary。以这种方式短路SCons的内置依赖跟踪似乎效率很低。有没有人知道正确的SCons-y方式呢？
答案 0 :(得分：0)
我指的是你的最新评论：它看起来好像这不是一个SCons问题，而是更多的一般链接器问题（XY问题）。您可能只是在搜索RPATH吗？另请查看旧的SO问题：scons executable + shared library in project directory