libelektra 🚀 - 某些测试在 OS X 上失败

抱歉，我没有 OS X。不过ctest -V是你的朋友。

manuelm 于 2016-04-26

👍1

顺便说一句，调用lua $file与运行测试不同。您正在使用系统安装的 kdb 库，而测试显然使用位于构建目录中的库。您至少应该设置LUA_CPATH 。见https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/swig/lua/tests/CMakeLists.txt#L12

90% 与 swig 相关的崩溃与构建环境故障有关。所以首先尝试重新生成（！）+ 重新编译 swig 绑定。

manuelm 于 2016-04-26

此问题可能与 ad537b3 相关（至少在 Linux 上 kdb*lua|python 崩溃了，但针对 Linux 的修复是 ad537b3 的一部分）。如果没有测试的输出，就无法真正分辨。

您可以使用make run_all来抑制成功测试用例的输出，但显示失败测试用例的输出。

markus2330 于 2016-04-26

@sanssecours 有任何更新吗？

manuelm 于 2016-05-09

此问题可能与 ad537b3 相关（至少在 Linux 上 kdb*lua|python 崩溃了，但针对 Linux 的修复是 ad537b3 的一部分）。如果没有测试的输出，就无法真正分辨。
@sanssecours 有任何更新吗？

回复晚了非常抱歉。我以为我已经写了一条评论，其中包含有关此问题的扩展信息。首先让我说testpy2_kdb.py在我的机器上也失败了。所以这可能是我的特定设置有问题。我通过 Homebrew 安装了SWIG ，目前使用以下cmake命令为 Elektra 生成构建文件：

cmake .. -GNinja -DENABLE_TESTING=ON -DCMAKE_PREFIX_PATH=/usr/local/opt/qt5 -DTOOLS='qt-gui;kdb' -DBUILD_PDF=ON -DBINDINGS=SWIG

这是ctest -V -R test_kdb.lua的输出：

test 65
    Start 65: test_kdb.lua

65: Test command: /usr/local/bin/lua "/Users/rene/Dropbox/Studium/Master Thesis/Configuration Parsing/Source/Elektra/src/bindings/swig/lua/tests/test_kdb.lua"
65: Environment variables:
65:  LUA_CPATH=/Users/rene/Dropbox/Studium/Master Thesis/Configuration Parsing/Source/Elektra/build/src/bindings/swig/lua/?.so
65: Test timeout computed to be: 1500
65: /usr/local/bin/lua: kdb:1 Warning was issued:
65:  Warning number: 1
65:     Description: could not load module, dlopen failed
65:     Ingroup: modules
65:     Module: dl
65:     At: ../src/libs/loader/dl.c:82
65:     Reason: of module: libelektra-resolver.so, because: dlopen(libelektra-resolver.so, 2): image not found
65:     Mountpoint:
65:     Configfile:
65: Error (#40) occurred!
65: Description: Failed to open default backend (see warnings for more information)
65: Ingroup: kdb
65: Module:
65: At: ../src/libs/elektra/kdb.c:282
65: Reason: could not open default backend
65: Mountpoint:
65: Configfile:
65:
65: stack traceback:
65:     [C]: in ?
65:     [C]: in function 'KDB'
65:     .../Source/Elektra/src/bindings/swig/lua/tests/test_kdb.lua:20: in main chunk
65:     [C]: in ?
1/1 Test #65: test_kdb.lua .....................***Failed    0.00 sec

0% tests passed, 1 tests failed out of 1

Label Time Summary:
bindings    =   0.00 sec (1 test)
kdbtests    =   0.00 sec (1 test)
memleak     =   0.00 sec (1 test)

Total Test time (real) =   0.01 sec

The following tests FAILED:
     65 - test_kdb.lua (Failed)
Errors while running CTest

看起来 Lua 无法找到libelektra-resolver.so ，它位于我的机器上的build/lib和/usr/local/lib/elektra 。我需要为此设置一些库路径吗？顺便说一下，看起来testpy2_kdb.py也因为同样的问题而失败。

sanssecours 于 2016-05-09

绑定不会在运行时加载任何 elektra 库。它们只是绑定。您可以通过查看确切的错误位置来看到这一点，即../src/libs/loader/dl.c:82 。

因此，这要么是您的环境问题，要么是 OSX 上的一般 elektra 问题，要么是 OSX 上的构建系统问题。我怀疑是前者。平@markus2330

manuelm 于 2016-05-09

dlopen(libelektra-resolver.so, 2): image not found其实看起来跟lua没什么关系。

libelektra-resolver.so应该是您使用KDB_DEFAULT_RESOLVER选择的解析器的符号链接，也许您的设置/安装已损坏？你能检查符号链接是否正确吗？

奇怪的是： libelektra-resolver.so用在每个kdb相关的测试用例中，为什么在这个测试用例中只有_not_起作用？也许这个测试用例（和 python 一个）使用已安装的库而不是构建目录中的库。你能用 strace 检查测试用例试图加载哪个libelektra-resolver.so吗？

image not found非常通用，可能是在库中找不到您的架构的图像？你使用胖二进制文件吗？

markus2330 于 2016-05-09

libelektra-resolver.so应该是您使用KDB_DEFAULT_RESOLVER选择的解析器的符号链接，也许您的设置/安装已损坏？

有没有一种简单的方法可以检查本地 Elektra 安装是否损坏？命令kdb似乎有效。

你能检查符号链接是否正确吗？

libelektra-resolver.so别名都链接到与别名位于同一目录中的文件libelektra-resolver_fm_hpu_b.so 。所以看起来他们是正确的。

你能用 strace 检查测试用例试图加载哪个libelektra-resolver.so吗？

我试过sudo dtruss ctest -V -R test_kdb.lua 。这是输出：
test_kdb.lua - dtruss 输出.txt 。看起来测试使用了构建目录中的 Elektra 版本。我通过sudo ninja uninstall卸载了 Elektra。然后我再次运行测试。输出还是一样的。

你使用胖二进制文件吗？

不是我所知道的。

sanssecours 于 2016-05-09

你使用 OSX El Capitan 吗？这可能是一个奇怪的系统完整性保护问题。

markus2330 于 2016-05-09

有点奇怪kdb可以工作。

manuelm 于 2016-05-09

如果由于 python/lua 安装而与系统完整性保护有关，它可能是有意义的。

markus2330 于 2016-05-09

你使用 OSX El Capitan 吗？这可能是一个奇怪的系统完整性保护问题。

是的，我使用 OS X 10.11.4。我暂时禁用了 SIP 并再次运行测试。还是一样的问题。虽然，在我禁用 SIP 后，我遇到了一个失败的新测试： testscr_check_kdb_internal_suite 。现在testscr_check_merge也不再起作用了😢。

我回到 0.8.16，清理我的构建目录并再次运行ninja test 。 testscr_check_kdb_internal_suite和testscr_check_merge仍然失败，尽管我记得，至少testscr_check_kdb_internal_suite在 Elektra 0.8.16 发布时有效。这是现在也失败的附加测试的输出：
testscr_check_kdb_internal_suite.txt
testcr_check_merge.txt

sanssecours 于 2016-05-10

我已经更改了标题并删除了自己。我无法直接访问 OSX 机器并且缺乏深入的知识。没有机器可以四处闲逛，我无法从文本输出中分辨出任何东西。

manuelm 于 2016-05-10

您是否还查看了链接的其他提示？例如重新安装python/lua？

@petermax2 @mpranj你能重现这些问题吗？

markus2330 于 2016-05-10

您是否还查看了链接的其他提示？例如重新安装python/lua？

对不起，不是真的。 Python 2 安装是系统附带的安装。要重新安装它，我必须重新安装整个操作系统。

我安装 Lua 只是为了测试 Lua Elektra 插件。所以我认为重新安装没有多大意义。但是，由于只需要几秒钟，我执行了brew reinstall lua 。之后，我从一个干净的构建目录开始，运行构建命令和ctest -VV -R test_kdb.lua 。测试仍然显示相同的输出。

顺便说一句：在我从/etc/kdb删除所有文件之后，测试testscr_check_kdb_internal_suite和testscr_check_merge现在也可以正常工作/etc/kdb 。

sanssecours 于 2016-05-10

我目前没有其他想法。（除了耗时的问题隔离：将 dlopen 调用减少到不起作用的最小示例）因此，如果有人可以重现该问题，最好等待，也许它会为问题带来新的线索。

markus2330 于 2016-05-10

👍1

我可以在我的机器上确认相同的行为。

解决方法：正确设置库路径：eg
LD_LIBRARY_PATH="/Users/mpranj/workspace/libelektra/build/lib" ctest -V -R test_kdb.lua对我来说很好用。

dlopen在 OS X 上搜索$LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH ，我认为是这个顺序。

PR #710 修复了它，但是我不确定修复是否非常干净。

mpranj 于 2016-05-10

❤1

不，修复肯定不干净。

据我所知，我们的测试依赖于在libelektra-kdb.so设置的DT_RPATH libelektra-kdb.so 。如果这在 OSX 上不可用，我们应该在某个全局构建环境中定义它。

编辑：但感谢您发现！

manuelm 于 2016-05-10

RPATH是为所有核心库设置的，但也许libelektra-core就足够了：在这个地方dlopen发生了。

image not found仅表示未找到库？如果是这样，知道为什么RPATH对除 lua 和 python 测试之外的所有测试都有效吗？

markus2330 于 2016-05-10

仅供参考：Elektra 还通过简单地将TARGET_PLUGIN_FOLDER设置为空字符串来支持没有RPATH （例如，使用 musl 作为 libc 的 openwrt）。

markus2330 于 2016-05-10

顺便说一下，FreeBSD 上似乎也发生了类似的事情。

 66/118 Test  #66: test_kdb.py ........................***Failed    0.09 sec
..EEEE
======================================================================
ERROR: test_ctor (__main__.KDB)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mpranj/workspace/libelektra/src/bindings/swig/python/tests/test_kdb.py", line 25, in test_ctor
    self.assertIsInstance(kdb.KDB(), kdb.KDB)
  File "/home/mpranj/workspace/libelektra/build/src/bindings/swig/python/kdb.py", line 1742, in __init__
    _kdb.KDB_swiginit(self, _kdb.new_KDB(*args))
kdb.KDBException: 1 Warning was issued:
 Warning number: 1
    Description: could not load module, dlopen failed
    Ingroup: modules
    Module: dl
    At: /home/mpranj/workspace/libelektra/src/libs/loader/dl.c:82
    Reason: of module: libelektra-resolver.so, because: Shared object "libelektra-resolver.so" not found, required by "python3"
    Mountpoint:
    Configfile:
Error (#40) occurred!
Description: Failed to open default backend (see warnings for more information)
Ingroup: kdb
Module:
At: /home/mpranj/workspace/libelektra/src/libs/elektra/kdb.c:282
Reason: could not open default backend
Mountpoint:
Configfile:

还不能在 FreeBSD 上检查 lua。

mpranj 于 2016-05-10

@mpranj很高兴知道，所以如果 FreeBSD 也适用于 MacOSX（在 OpenBSD 旁边），它似乎是一个很好的提示。其他kdb测试用例和kdb命令行工具是否有效？

您能否针对在 FreeBSD 上不起作用的测试用例提出问题或附加到 OpenBSD 问题中？

markus2330 于 2016-05-10

如果你的意思是这些：

        Start 115: testkdb_allplugins
115/118 Test #115: testkdb_allplugins .................   Passed    0.02 sec
        Start 116: testkdb_nested
116/118 Test #116: testkdb_nested .....................   Passed    0.27 sec
        Start 117: testkdb_conflict
117/118 Test #117: testkdb_conflict ...................   Passed    0.17 sec
        Start 118: testkdb_simple
118/118 Test #118: testkdb_simple .....................   Passed    0.42 sec

... 好的。 kdb工具似乎可以工作（只需使用 ls 快速检查一下）。

否则很多事情都失败了，但我今天无法检查/报告所有内容。但是当我正确测试时，我肯定会报告所有内容。

mpranj 于 2016-05-10

我的猜测是 kdb 测试有效，因为它们是静态链接的，对吗？
如果我禁用BUILD_STATIC测试也不起作用。

@markus2330我认为我们无法避免在某些平台上设置LD_LIBRARY_PATH 。 TARGET_PLUGIN_FOLDER是如何工作的？或者更具体地说，这是如何解决动态库搜索的？

manuelm 于 2016-05-12

谢谢，这是个好主意： @sanssecours你能禁用 BUILD_STATIC 和 BUILD_FULL 并重新运行所有 ( testkdb ) 测试吗？

如果 TARGET_PLUGIN_FOLDER 为空，则插件安装在库所在的位置，不需要RPATH或LD_LIBRARY_PATH 。但它只会在使用已安装的 Elektra 时有所帮助（ python / lua测试可能就是这种情况）。

https://cmake.org/Wiki/CMake_RPATH_handling说“.. Mac OS X 上的 RPATH。它将为构建树和安装树启用”，因此实际上构建树二进制文件也应该设置 RPATH。 @sanssecours你能检查一下吗？例如使用readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH 。

markus2330 于 2016-05-15

问题不在于 RPATH 本身，而在于 Linux 上的dlopen读取 DT_RPATH 与其他平台。

man dlopen来自 glibc：

（仅限 ELF）如果调用程序的可执行文件包含 DT_RPATH 标记，但不包含 DT_RUNPATH 标记，则搜索 DT_RPATH 标记中列出的目录。
如果在程序启动时将环境变量 LD_LIBRARY_PATH 定义为包含以冒号分隔的目录列表，则搜索这些目录。（作为安全措施，set-user-ID 和 set-group-ID 程序忽略此变量。）
（仅限 ELF）如果调用程序的可执行文件包含 DT_RUNPATH 标记，则搜索该标记中列出的目录。
检查缓存文件 /etc/ld.so.cache（由 ldconfig(8) 维护）以查看它是否包含文件名条目。
搜索目录 /lib 和 /usr/lib（按该顺序）。

man dlopen在 OSX 上：

当路径不包含斜杠字符（即它只是一个叶子名称）时，dlopen() 将搜索以下内容，直到找到兼容的 Mach-O 文件：$LD_LIBRARY_PATH、$DYLD_LIBRARY_PATH、当前工作目录、$DYLD_FALLBACK_LIBRARY_PATH。

manuelm 于 2016-05-15

dlopen 应该在这里使用绝对路径，或者它需要在上面提到的路径之一中

mpranj 于 2016-05-15

但是我们不做绝对路径。所以不知道这些信息有什么帮助

manuelm 于 2016-05-15

绝对 RPATH 或插件的绝对路径？ CMake 声称它支持构建树 RPATH，因此如果需要，它应该使用绝对 RPATH。

插件的绝对路径是许多人所做的，这将是一个简单的更改，但我不知道它对内置测试用例有何帮助。

首先，这里的实际问题是什么会很有趣。安装的版本真的完全有效吗？例如kdb run_all也会很有趣（在我上面写的旁边）。

markus2330 于 2016-05-15

我从 dlopen 联机帮助页粘贴的内容清楚地说明了问题所在。
dlopen(libelektra-resolver.so) 的搜索路径在不同平台上是不同的。 Linux 工作是因为 dlopen 尊重 libelektra-kdb.so 的 DT_RPATH

manuelm 于 2016-05-15

似乎设置LD_LIBRARY_PATH也是 Valve 也在做的事情。
https://github.com/ValveSoftware/steam-runtime/blob/master/runtime/run.sh

mpranj 于 2016-05-15

你的意思是他们不写文档的问题？ @rpath甚至没有在那里提到。

我认为，在我们不知道安装/使用 BUILD_SHARED 时实际工作的内容之前，我们不应该进一步推测。

markus2330 于 2016-05-15

@markus2330
编辑：禁用 BUILD_STATIC 和 BUILD_FULL：
testkdb* 测试运行良好。

mpranj 于 2016-05-15

关于文档，他们在这里提到了@rpath 。

mpranj 于 2016-05-15

刚刚通过一个简短的例子验证了我的陈述：

runtimelib ...一个提供一些随机函数的库。（如 elektra-resolver）
lib ...在运行时使用dlopen加载runtimelib的库。它已将 DT_RPATH 设置为runtimelib 。（如绑定的 kdb.so）
runner ...在运行时使用dlopen加载lib的可执行文件（如 lua/python）

见https://gist.github.com/manuelm/43a4fa9dd424b4dcf03bd1d773a0e122

这种情况在 Linux 上有效，但在 FreeBSD 上失败。

manuelm 于 2016-05-15

我知道在库中设置的 RPATH 不可移植（它也不适用于 musl）。但它似乎适用于 Mac OS X（ @mpranj还报告说 testkdb* 测试工作正常， @omnidan报告kdb可用于 Mac OS X）。因此我要求调查为什么只有 python/lua 测试失败。

安装 Elektra 的便携方式不是设置TARGET_PLUGIN_FOLDER并且我们可以使用（如建议的） LD_LIBRARY_PATH 。（我们只需要在 run_memcheck 和 run_all 中设置它）。

markus2330 于 2016-05-15

@mpranj还报告 testkdb* 测试工作正常， @omnidan报告 kdb 与 Mac OS X 兼容

testkdb*和kdb让 DT_RPATH 自行设置。 Python 和 lua 解释器没有。那是根本不同的。

[...] 对于测试，我们可以使用（如建议的）LD_LIBRARY_PATH。

那么请添加。谢谢

manuelm 于 2016-05-15

是的，您适合构建系统：CMake 似乎在每个可执行文件上都设置了 RPATH，但显然不适用于 python/lua。

然而，当安装时，它不会被设置。所以请有人确认kdb有效（设置TARGET_PLUGIN_FOLDER ）。

markus2330 于 2016-05-15

@sanssecours你能禁用 BUILD_STATIC 和 BUILD_FULL 并重新运行所有（ testkdb ）测试吗？

看起来这并没有太大变化，只是ninja test运行的测试更少（54 而不是 114）。测试test_kdb.lua和testpy2_kdb.py仍然失败。所有其他测试（似乎）都有效。

https://cmake.org/Wiki/CMake_RPATH_handling说“.. Mac OS X 上的 RPATH。它将为构建树和安装树启用”，因此实际上构建树二进制文件也应该设置 RPATH。例如使用readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH 。

我使用了命令otool -l lib/libelektra-resolver.so - libelektra-core.so.0.8.16在我的机器上不存在。根据输出：

…
Load command 12
          cmd LC_RPATH
      cmdsize 104
         path /Users/rene/Dropbox/Studium/Master Thesis/Configuration Parsing/Source/Elektra/build/lib (offset 12)
…

RPATH已设置。

例如 kdb run_all 也会很有趣（在我上面写的旁边）。

在我的机器上，655 次测试中有 5 次失败。 4 个测试（ testmod_crypto 、 testmod_iterate 、 testmod_semlock和testmod_template ）由于相同的基本错误而失败：

dyld: Library not loaded: @rpath/libelektra-full.4.dylib
  Referenced from: /usr/local/lib/elektra/tool_exec/testmod_crypto
  Reason: Incompatible library version: testmod_crypto requires version 4.0.0 or later, but libelektra-full.4.dylib provides version 0.0.0
/usr/local/lib/elektra/tool_exec/run_all: line 1070: 76960 Trace/BPT trap: 5       "$KDB" $t
error: testmod_crypto

dyld: Library not loaded: @rpath/libelektra-full.4.dylib
  Referenced from: /usr/local/lib/elektra/tool_exec/testmod_iterate
  Reason: Incompatible library version: testmod_iterate requires version 4.0.0 or later, but libelektra-full.4.dylib provides version 0.0.0
/usr/local/lib/elektra/tool_exec/run_all: line 1070: 77093 Trace/BPT trap: 5       "$KDB" $t
error: testmod_iterate

dyld: Library not loaded: @rpath/libelektra-full.4.dylib
  Referenced from: /usr/local/lib/elektra/tool_exec/testmod_semlock
  Reason: Incompatible library version: testmod_semlock requires version 4.0.0 or later, but libelektra-full.4.dylib provides version 0.0.0
/usr/local/lib/elektra/tool_exec/run_all: line 1070: 77239 Trace/BPT trap: 5       "$KDB" $t
error: testmod_semlock

dyld: Library not loaded: @rpath/libelektra-full.4.dylib
  Referenced from: /usr/local/lib/elektra/tool_exec/testmod_template
  Reason: Incompatible library version: testmod_template requires version 4.0.0 or later, but libelektra-full.4.dylib provides version 0.0.0
/usr/local/lib/elektra/tool_exec/run_all: line 1070: 77272 Trace/BPT trap: 5       "$KDB" $t
error: testmod_template

测试testmod_python2显示以下错误输出：

PYTHON      TESTS
==================

Testing simple variable passing...
There are 1 warnings
buffer is: warnings/#00
number: 11
description: open of plugin returned unsuccessfully (reason contains plugin, see other warnings for details)
ingroup: kdb
module:
file: ../src/libs/elektra/plugin.c
line: 297
reason: python2
reason:
reason:
../src/plugins/python2/../python/testmod_python.c:53: error in test_variable_passing: warnings in kdbOpen for plugin python2
number: 111
description: : python error
ingroup: : plugin
module: : python
at: ../src/plugins/python2/../python/python.cpp:245
reason: : Unable to import kdb module
mountpoint: :
configfile: :
../src/plugins/python2/../python/testmod_python.c:53: error in test_variable_passing: error in kdbOpen for plugin python2
../src/plugins/python2/../python/testmod_python.c:53: fatal in test_variable_passing: could not open python2 plugin
error: testmod_python2

下面是testmod_lua的输出，它没有报告错误。

--- running testmod_lua ---


LUA         TESTS
==================

Testing simple variable passing...
[LUA-1] open -->
[LUA-1] get
[LUA-1] <-- close
Testing loading of two active lua plugins...
[LUA-1] open -->
[LUA-2] open -->
[LUA-2] <-- close
[LUA-1] <-- close

========================================================================
NOTE: The following errors are intended. We're testing error conditions!
========================================================================
Testing return values from lua functions...
Testing lua script with syntax error...
There are 1 warnings
buffer is: warnings/#00
number: 11
description: open of plugin returned unsuccessfully (reason contains plugin, see other warnings for details)
ingroup: kdb
module:
file: ../src/libs/elektra/plugin.c
line: 297
reason: lua
reason:
reason:
number: 131
description: : lua error
ingroup: : plugin
module: : lua
at: ../src/plugins/lua/lua.cpp:80
reason: : /usr/local/share/elektra/test_data/lua/lua_plugin_wrong.lua:2: attempt to call global 'wrong' (a nil value)
mountpoint: :
configfile: :

test_lua RESULTS: 29 test(s) done. 0 error(s).

sanssecours 于 2016-05-16

在 OS X 上创建 dylib，而不是 .so。肯定有 libelektra-core.0.8.16.dylib 或类似的。

mpranj 于 2016-05-16

肯定有 libelektra-core.0.8.16.dylib 或类似的。

你是对的。看起来RPATH没有为libelektra-core.0.8.16.dylib ，因为otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH没有显示输出。

sanssecours 于 2016-05-16

不要 grep 输出很短，或者 grep 小写 rpath

mpranj 于 2016-05-16

不要 grep 输出很短，或者 grep 小写 rpath

你的意思是“不要 grep 输出，那很短，还是 grep 小写的 rpath”？如果是这样，为什么不呢？我还通过我的终端应用程序的内置搜索在otool -l lib/libelektra-core.0.8.16.dylib的输出中搜索了RPATH 。这也表明没有出现LC_RPATH 。

如果我搜索rpath ，那么我会看到@rpath ：

...
Load command 3
          cmd LC_ID_DYLIB
      cmdsize 56
         name @rpath/libelektra-core.4.dylib (offset 24)
   time stamp 1 Thu Jan  1 01:00:01 1970
      current version 0.0.0
compatibility version 0.0.0
...

据我所知@rpath只是（存储在的值） RPATH的占位符。我不认为rpath告诉我们是否设置了RPATH 。

根据CMake wiki ，命令otool -l <file> | grep LC_RPATH -A2是显示某个文件的 RPATH 的一种可能方式。我认为我使用的不太花哨的版本—— otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH ——也应该或多或少不错。

sanssecours 于 2016-05-16

伙计们，你为什么要检查这个？

manuelm 于 2016-05-16

@sanssecours抱歉，我从手机上快速发送了消息，所以我认为它没有意义。

我指的是otool -L ，它显示了依赖关系并且只显示@rpath 。但是是的，你是对的otool -l是正确的命令。

顺便说一句，除了 elektra，我还没有在我的系统中找到一个使用 RPATH 的库。

/usr/local/lib/libelektra.0.8.13.dylib
          cmd LC_RPATH
      cmdsize 40
         path /usr/local/lib/elektra (offset 12)

正如@manuelm所说，这些检查可能毫无意义......

mpranj 于 2016-05-16

我不认为我们完全理解上述所有问题，但我同意我们正在做的那种远程调试效率不高。有人应该调查并记录支持非 glibc 系统的最佳方式。让我们在会议上讨论如何进行。

markus2330 于 2016-05-16

@markus2330我完全理解这个问题。在测试开始之前设置 LD_LIBRARY_PATH，我保证问题消失了。

所有其他提到的问题都是红鲱鱼或只是错误的。

manuelm 于 2016-05-16

@manuelm我想表现得很好并说“我们”。显然 LD_LIBRARY_PATH 将解决在构建目录中找不到库的问题（除非它在某处被重置，至少对于 python/lua GI 测试来说似乎是这种情况）。但是，如果您的理论是正确的，必须在二进制文件中设置 RPATH，那么安装的版本也会被破坏，目前尚未真正确认。这应该被调查。

markus2330 于 2016-05-16

我的理论不再只是一个理论，因为我已经完成了证明。

再一次：在 linux 上，绑定工作是因为实现绑定的库（lua/python 为kdb.so libgelektra-4.0.so ，glib 为DT_RPATH _AND_ dlopen尊重这一点。

当然，在将 elektra 安装到全局系统库路径后，绑定将起作用。我绝对看不出为什么这会突然停止工作。

绑定测试不适用于 !=linux。就这样。

manuelm 于 2016-05-16

PS：我知道 GI 绑定测试需要 LD_LIBRARY_PATH。这就是为什么我希望您添加某种构建系统宏来集成/附加 GI 案例。

manuelm 于 2016-05-16

似乎绑定测试是唯一需要 LD_LIBRARY_PATH 的地方，所以我就在那里添加了它。

@mpranj希望我们很快得到一个可以确认它是否有效的 travis？

markus2330 于 2016-05-19

@markus2330不，它不起作用。（既不在 travis 上也不在我的机器上）

mpranj 于 2016-05-21

@mpranj感谢您的测试。您是否准备好 travis 文件以在不打扰他人的情况下再次对其进行测试？两个测试用例仍然失败？我是否在某处忘记了 LD_LIBRARY_PATH 或者该方法根本不起作用？

markus2330 于 2016-05-21

@markus2330是的，我目前正在 travis 上进行测试，但它的行为与我的机器上的行为大致相同。似乎 da243f9e25d8fa14f8286c48b4338a73c1e7242d 没有区别。

mpranj 于 2016-05-21

你可以在这里看到它： https :
顺便说一句， @manuelm似乎是用 travis+OS X 完成的。测试失败了，但我猜 travis 实际上几乎完全设置好了。

mpranj 于 2016-05-21

是的，他是这么说的。主要是缺少使用一个 travis 文件构建 Mac OS X 和其他人的矩阵设置。

markus2330 于 2016-05-21

感谢您的所有帮助，问题现在应该得到解决。

markus2330 于 2016-05-31

Libelektra: 某些测试在 OS X 上失败

所有57条评论

相关问题