Scons 将磁盘名称前缀添加到 NFS LIBPATH
你好，我正在用 Scons 构建环境。 对于 Windows 平台（链接）链接器获取 Scons 设置 我的共享库路径的前缀 - 磁盘名称
我在 NFS 上有库：
libs='\\\\share\\lib\\lib'
在 scons 中我有：
env.Append(LIBPATH = [libs])
结果是链接器调用如下内容：
/LIBPATH:D:\share\lib\lib
Hi I'm building environment with Scons.
For Windows platform (link) linker gets Scons setup
of my share library path with prefix - disk name
I've library on NFS:
libs='\\\\share\\lib\\lib'
In scons I have:
env.Append(LIBPATH = [libs])
result is that the linker invokes something like this:
/LIBPATH:D:\share\lib\lib
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看起来追加功能正在更改您的输入。您是否尝试过通过 __set_item__ 接口操作“LIBPATH”？尝试：
或者
另外，如果你想摆脱 python \escape-hell，你可以使用字符串前缀 r ，它代表“raw”，并且你的所有 \ 都将不受干扰地通过。
编辑：
为了回应作者的评论并为了调试进一步的尝试：
如果您在最后一次打印中看到 env['LIBPATH'] 中的正确值，则 scons 中的其他内容正在破坏您的输入。如果要附加到 lib 路径的字符串不正确，请尝试在 python 解释器中操作该字符串。执行-> <运行...>。然后输入“python”。这将为您提供一个交互式 python 终端，您可以尝试进行字符串操作。如果执行该命令序列不起作用，您可以尝试在某个位置找到 python 安装并双击 python.exe 文件。
It looks like the Append function is changing your input. Have you tried manipulating 'LIBPATH' through the __set_item__ interface? Try:
or
Also, if you want to get out of python \escape-hell, you can use the string prefix r which stands for "raw" and all your \'s will be passed through unmolested.
EDIT:
In response to the author's comment and in order to debug this further try:
If you see the correct value in env['LIBPATH'] on the last print, then something else in scons is mangling your input. If the string you want to append to the lib path is incorrect, try manipulating the string in the python interpreter. Do <Windows start> -> <Run ...>. Then type 'python'. This should give you an interactive python terminal and you can experiment with string manipulation. If doing that sequence of commands doesn't work, you can try to find your python install someplace and double-click the python.exe file.
这里问题的根源是 SCons 将 LIBS 数组中找到的库添加到链接器命令行中 - 带有完整路径。这会导致链接器将此完整路径名保存到生成的可执行文件中，这是不幸的，特别是如果我们正在构建一些稍后将安装到系统目录中的库。我不确定我们是否可以为此归咎于 SCons，因为链接器需要找到用于链接它的库。
到目前为止我只能找到以下两种解决方案：
之后（例如使用 Install() 构建器）。这仅产生名称
库最终位于
为了配置正确的依赖关系
两种解决方案似乎都有点尴尬......
PS：（编辑）但是有一个不可移植的解决方案。您可以将特定选项传递给链接器。特别是，在 GNU/Linux 系统上，您可以使用 -h 选项显式设置 DT_SONAME。当库包含此显式设置的 DT_SONAME 字段时，其他库或可执行文件中的任何引用都将仅使用该名称 - 在调用时将精确的解析留给链接器。通常，这正是我们在构建稍后安装到系统中的新库时想要的
The root of the problem here is that SCons adds the libs found in the LIBS array to the linker commandline -- with full path. This results in the linker saving this full pathname into the generated executable, which is unfortunate, especially if we're building some libs which will be installed into a system directory later on. I'm not sure if we can blame SCons for that, because the linker needs to find the library for linking against it.
I could only find the following two solutions up to now:
afterwards (e.g. with the Install() builder). This results in just the name of the
library ending up in the executable
for configuring the right dependencies
both solutions seem somewhat awkward....
PS: (edit) there is a non-portable solution though. You may pass specific options to the linker. Especially, on a GNU/Linux system, you may explicitly set the DT_SONAME with the -h option. When a library contains this explicity set DT_SONAME field, then any referrals in other libs or executables will just use that name -- leaving the exact resolution to the linker at invokation time. Usually this is exactly what we want, when building a new library to be installed later into the system