Libelektra: 一部のテストはOSXで失敗します

申し訳ありませんが、私はOS Xを持っていません。しかし、 ctest -Vはあなたの友達です。

ところで、 lua $file呼び出すことは、テストを実行することと同じではありません。 テストでは明らかにビルドディレクトリにあるライブラリを使用していますが、システムにインストールされたkdbライブラリを使用しています。 少なくともLUA_CPATH設定する必要があります。 https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/swig/lua/tests/CMakeLists.txt#L12を参照して

スウィッグ関連のクラッシュの90％は、ビルド環境の障害に関連していました。 したがって、最初にregenerate（！）+ swigバインディングを再コンパイルしてみてください。

この問題はad537b3に関連している可能性があります（少なくともLinuxではkdb * lua | pythonがクラッシュしていましたが、Linuxの修正はad537b3の一部です）。 テストの出力がなければ、実際にはわかりません。

make run_allを使用すると、成功したテストケースの出力は抑制されますが、失敗したテストケースの出力は表示されます。

@sanssecoursこれに関する更新はありますか？

この問題は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は私のマシンのbuild/libと/usr/local/lib/elektraにあるlibelektra-resolver.soを見つけることができないようです。 これを機能させるには、ライブラリパスを設定する必要がありますか？ ちなみに、同じ問題が原因でtestpy2_kdb.pyも失敗しているようです。

バインディングは、実行時にelektraライブラリをロードしません。 それらは単なるバインディングです。 これは、正確なエラーの場所である../src/libs/loader/dl.c:82を確認することで確認できます。

したがって、これは環境の問題、OSXの一般的なelektraの問題、またはOSXのビルドシステムの問題のいずれかです。 前者だと思います。 ping @ markus2330

dlopen(libelektra-resolver.so, 2): image not found実際にはluaとは何の関係もないように見えます。

libelektra-resolver.soは、 KDB_DEFAULT_RESOLVERで選択したリゾルバーへのシンボリックリンクである必要があります。セットアップ/インストールが壊れている可能性がありますか？ シンボリックリンクが正しいかどうかを確認できますか？

奇妙なことに、 libelektra-resolver.soはすべてのkdb関連のテストケースで使用されていますが、なぜこのテストケースでは機能しないのですか？ たぶん、このテストケース（およびPythonのもの）は、ビルドディレクトリ内のライブラリではなく、インストールされたライブラリを使用します。 テストケースがロードしようとしているlibelektra-resolver.soをstraceで確認できますか？

image not foundは非常に一般的ですが、ライブラリ内にアーキテクチャのイメージが見つからない可能性がありますか？ ファットバイナリを使用していますか？

libelektra-resolver.soは、 KDB_DEFAULT_RESOLVERで選択したリゾルバーへのシンボリックリンクである必要があります。セットアップ/インストールが壊れている可能性がありますか？

ローカルのElektraインストールが壊れているかどうかを確認する簡単な方法はありますか？ コマンドkdbは機能しているようです。

シンボリックリンクが正しいかどうかを確認できますか？

両方のlibelektra-resolver.soエイリアスは、エイリアスと同じディレクトリにあるファイルlibelektra-resolver_fm_hpu_b.soにリンクしています。 したがって、それらは正しいように見えます。

テストケースがロードしようとしているlibelektra-resolver.soをstraceで確認できますか？

sudo dtruss ctest -V -R test_kdb.luaを試しました。 出力は次のとおりです。
test_kdb.lua-dtrussOutput.txt 。 テストではビルドディレクトリのElektraバージョンを使用しているようです。 sudo ninja uninstallを介してElektraをアンインストールしました。 その後、もう一度テストを実行しました。 出力は同じです。

ファットバイナリを使用していますか？

私が知っていることではありません。

OSX El Capitanを使用していますか？ これは、奇妙なシステム整合性保護の問題である可能性があります。

kdb機能するのはちょっと奇妙です。

python / luaのインストールが原因でシステム整合性保護に関係している場合は、それが理にかなっている可能性があります。

OSX El Capitanを使用していますか？ これは、奇妙なシステム整合性保護の問題である可能性があります。

はい、OS X10.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はどちらも失敗しますが、Elektra 0.8.16がリリースされたとき、少なくともtestscr_check_kdb_internal_suite機能したことを覚えています。 現在も失敗している追加のテストの出力は次のとおりです。
testscr_check_kdb_internal_suite.txt
testscr_check_merge.txt

タイトルを変更して自分を削除しました。 私はOSXマシンに直接アクセスできず、深い知識が不足しています。 突く機械がなければ、テキスト出力からは何もわかりません。

リンクの他のヒントも見ましたか？ たとえば、python / luaを再インストールしますか？

@ petermax2 @mpranjこれらの問題を再現できますか？

リンクの他のヒントも見ましたか？ たとえば、python / luaを再インストールしますか？

申し訳ありませんが、そうではありません。 Python 2のインストールは、システムに付属しているものです。 再インストールするには、オペレーティングシステム全体を再インストールする必要があります。

LuaElektraプラグインをテストするためだけにLuaをインストールしました。 したがって、再インストールはあまり意味がないと思います。 ただし、数秒しかかからないため、 brew reinstall luaを実行しました。 その後、クリーンなビルドディレクトリから始めて、ビルドコマンドとctest -VV -R test_kdb.lua 。 テストでも同じ出力が表示されます。

ちなみに、 /etc/kdbからすべてのファイルを削除した後、テストtestscr_check_kdb_internal_suiteとtestscr_check_mergeも正しく機能するようになりました。

私は現在、別の考えを持っていません。 （時間のかかる問題の切り分けを除く：dlopen呼び出しを、機能しない最小限の例に減らすため）したがって、誰かが問題を再現できるかどうかを待つのが最善かもしれません。おそらく、問題に新たな光を当てるでしょう。

自分のマシンでも同じ動作を確認できます。

解決策：ライブラリパスを正しく設定します。例：
LD_LIBRARY_PATH="/Users/mpranj/workspace/libelektra/build/lib" ctest -V -R test_kdb.luaは私にとっては問題なく動作します。

OS Xのdlopenは$LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH検索しますが、この順序だと思います。

PR＃710で修正されましたが、修正が非常にクリーンかどうかはわかりません。

いいえ、修正は間違いなくクリーンではありません。

私が覚えている限り、私たちのテストはDT_RPATHがlibelektra-kdb.soに設定されていることに依存しています。 これがOSXで利用できない場合は、グローバルビルド環境の場所でこれを定義する必要があります。

編集：しかし、見つけてくれてありがとう！

RPATHはすべてのコアライブラリに設定されていますが、おそらくlibelektra-coreで十分です。この場所でdlopenが発生します。

image not found単にライブラリが見つからないことを意味しますか？ もしそうなら、なぜRPATHがluaとpythonのテスト以外のすべてで機能するのか考えてみてください。

参考までに：Elektraは、 TARGET_PLUGIN_FOLDERを空の文字列に設定するだけで、 RPATHないシステム（たとえば、libcとしてmuslを使用するopenwrt）もサポートします。

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は知ってkdbテストケースとkdbコマンドラインツールは機能しますか？

FreeBSDで動作しないテストケースに関する問題を開いたり、OpenBSDの問題に追加したりできますか？

あなたがこれらを意味するならば：

        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で簡単に確認してください）。

そうでなければ、多くのことが失敗していますが、今日はすべてをチェック/報告することができません。 しかし、適切にテストできたら、必ずすべてを報告します。

私の推測では、kdbテストは静的にリンクされているため、機能しますよね？
BUILD_STATICを無効にすると、テストも機能しません。

@ markus2330一部のプラットフォームでLD_LIBRARY_PATH 、 TARGET_PLUGIN_FOLDERはどのように機能していますか？ または、より具体的には、これはダイナミックライブラリ検索をどのように解決しますか？

ありがとうございます。 @ 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ます。

問題はRPATH自体に関するものではなく、LinuxでDT_RPATHと他のプラットフォームを読み取る場合のdlopenに関するものです。

glibcからのman dlopen ：

• （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が（この順序で）検索されます。

OSXのman dlopen ：

パスにスラッシュ文字が含まれていない場合（つまり、単にリーフ名である場合）、dlopen（）は、互換性のあるMach-Oファイルが見つかるまで、$ LD_LIBRARY_PATH、$ DYLD_LIBRARY_PATH、現在の作業ディレクトリ、$ DYLD_FALLBACK_LIBRARY_PATHを検索します。

dlopenはここで絶対パスで機能するか、上記のパスの1つにある必要があります

ただし、絶対パスは実行しません。 したがって、この情報がどのように役立つかわかりません

プラグインへの絶対RPATHまたは絶対パス？ CMakeは、ビルドツリーRPATHをサポートしていると主張しているため、必要に応じて絶対RPATHを使用する必要があります。

プラグインへの絶対パスは多くの人が行うことであり、簡単に変更できますが、ビルド内のテストケースにどのように役立たないかはわかりません。

まず、実際の問題がここにあるのは興味深いことです。 インストールされたバージョンは本当に完全に機能しますか？ たとえば、 kdb run_allも興味深いでしょう（私がすでに上で書いたものの隣に）。

dlopenのマンページからの私の貼り付けは、問題が何であるかを明確に述べています。
dlopen（libelektra-resolver.so）の検索パスは、プラットフォームによって異なります。 Linuxは、dlopenがlibelektra-kdb.soのDT_RPATHを尊重するために機能します。

LD_LIBRARY_PATHは、valveも行っていることのようです。
https://github.com/ValveSoftware/steam-runtime/blob/master/runtime/run.sh

問題は彼らがドキュメントを書かないということですか？ @rpathはそこにも言及されていません。

インストール時/ BUILD_SHAREDで実際に何が機能するかがわからなくなるまで、これ以上推測するべきではないと思います。

@ markus2330
編集：BUILD_STATICとBUILD_FULLを無効にする：
testkdb *テストは正常に実行されます。

ドキュメントについては、ここで@rpathについて言及しています。

短い例で私のステートメントを検証しました：

• runtimelib ...いくつかのランダムな関数を提供するライブラリ。 （elektra-resolverのように）
• lib ... dlopenを使用して実行時にruntimelibをロードするライブラリ。 DT_RPATHがruntimelibのディレクトリに設定されています。 （バインディングのkdb.soのように）
• runner ... dlopenを使用して実行時にlibをロードする実行可能ファイル（lua / pythonなど）

https://gist.github.com/manuelm/43a4fa9dd424b4dcf03bd1d773a0e122を参照して

このシナリオはLinuxで機能しますが、FreeBSDでは失敗します。

ライブラリに設定されたRPATHは移植性がないことを知っています（muslでも機能しませんでした）。 しかし、それはMac OS Xで機能するようでした（ 機能することも報告し、 @ omnidanはkdbがMac OS Xで機能することを報告しました）。 したがって、なぜpython / luaテストだけが失敗するのかを調査するように依頼しました。

Elektraをインストールするためのポータブルな方法は、 TARGET_PLUGIN_FOLDERを設定することではなく、テストには（提案されているように） LD_LIBRARY_PATH使用できます。 （run_memcheckとrun_all内でのみ設定する必要があります）。

@mpranjは、testkdb *テストが正常にomn​​idanは、kdbがMac

testkdb*とkdbは、DT_RPATHで自分で設定します。 Pythonとluaインタープリターはそうではありません。 それは根本的に異なります。

[...]そしてテストには（提案されているように）LD_LIBRARY_PATHを使用できます。

次に追加してください。 ありがとう

はい、あなたはビルドシステムに適しています。CMakeはすべての実行可能ファイルにRPATHを設定しているようですが、明らかにpython / luaには設定されていません。

ただし、インストールすると設定されません。 したがって、誰かがkdb機能するかどうかを確認してください（ TARGET_PLUGIN_FOLDER設定されています）。

@sanssecours BUILD_STATICとBUILD_FULLを無効にして、すべての（ testkdb ）テストを再実行できますか？

ninja testが実行するテストが少ない（114ではなく54）ことを除いて、これはそれほど変わらないように見えます。 テスト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).

OS Xでは、.soではなくdylibが作成されます。 間違いなくlibelektra-core.0.8.16.dylibまたは同様のものがあります。

間違いなくlibelektra-core.0.8.16.dylibまたは同様のものがあります。

あなたが正しいです。 otool -l lib/libelektra-core.0.8.16.dylib | grep RPATHは出力を表示しないため、 RPATHがlibelektra-core.0.8.16.dylibに設定されていないようです。

grepの出力が短い、またはgrepの小文字のrpathを使用しないでください

grepの出力が短い、またはgrepの小文字のrpathを使用しないでください

「出力をgrepしない、つまり短い、または小文字のrpathをgrepしない」という意味ですか？ もしそうなら、なぜですか？ 私はまた、検索RPATHの出力にotool -l lib/libelektra-core.0.8.16.dylibを経由して、組み込みの私のターミナルアプリケーションの検索。 これは、 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を表示する1つの可能な方法です。 私が使用したあまり派手でないバージョン– otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH –も多かれ少なかれうまくいくはずだと思います。

みんな、どうしてこれをチェックしているの？

@sanssecours申し訳ありませんが、電話からすぐにメッセージを送信したので、意味がないことがわかりませんでした。

依存関係を示し、 @rpathのみを表示するotool -Lを@rpath 。 しかし、そうです、あなたは正しいですotool -lは正しいコマンドです。

ところで、エレクトラを除いて、RPATHを使用しているライブラリがシステムに1つも見つかりませんでした。

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

@manuelmが述べているように、これらのチェックはかなり無意味かもしれません...

上記のすべての問題を完全に理解しているとは思いませんが、私たちが行っている種類のリモートデバッグは効率的ではないことに同意します。 誰かが非glibcシステムをサポートするための最良の方法を調査して文書化する必要があります。 会議でどのように進めるかについて話し合いましょう。

@ markus2330私はこの問題を完全に理解しています。 テストを開始する前にLD_LIBRARY_PATHを設定すると、問題がなくなることを約束します。

他のすべての言及された問題は、赤いニシンであるか、または単に間違っています。

@manuelm素敵になりたかったので、「私たち」と言いました。 明らかに、LD_LIBRARY_PATHは、ビルドディレクトリでライブラリが見つからないという問題を修正します（少なくともpython / lua GIテストの場合のように、どこかでリセットされない限り）。 しかし、RPATHをバイナリに設定する必要があるという理論が正しければ、インストールされているバージョンも壊れてしまいますが、これは現在実際には確認されていません。 これは調査する必要があります。

私の理論は、証明を行ったので、もはや単なる理論ではありません。

もう一度：Linuxでは、バインディングを実装するライブラリ（lua / pythonの場合はkdb.so libgelektra-4.0.so 、glibの場合はDT_RPATH設定されているため、バインディングは機能します_AND_ dlopenこれを尊重します。

もちろん、バインディングは、elektraがグローバルシステムライブラリパスにインストールされた後に機能します。 これが突然機能しなくなる理由はまったくわかりません。

バインディングのテストは！= linuxでは機能しません。 それで全部です。

PS：GIバインディングテストにはLD_LIBRARY_PATHが必要です。 そのため、GIケースを統合/追加するビルドシステムマクロを追加してほしいと思いました。

LD_LIBRARY_PATHが必要なのはバインディングテストだけのようですので、そこに追加しました。

@mpranjうまくいけば、それが機能するかどうかを確認できるトラビスをすぐに入手できますか？

@ markus2330いいえそれは機能しません。 （travisでも私のマシンでもありません）

@mpranjテストしてくれてありがとう。 誰かに迷惑をかけずにtravisファイルを再度テストする準備ができていますか？ 両方のテストケースはまだ失敗していますか？ LD_LIBRARY_PATHをどこかで忘れましたか、それともアプローチが機能していませんか？

@ markus2330はい私は現在

あなたはここでそれを見ることができます： https ：
ところで、 @ manuelmは

はい、彼はそう言った。 主に、1つのtravisファイルでMac OSXなどをビルドするためのマトリックスセットアップがありませんでした。

すべてのご協力に感謝します。問題は今すぐ修正されるはずです。