Libelektra: OS X에서 일부 테스트 실패

죄송하지만 저는 OS X가 없습니다. 그러나 ctest -V 은(는) 당신의 친구입니다.

lua $file 호출하는 btw는 테스트를 실행하는 것과 동일하지 않습니다. 테스트는 분명히 빌드 디렉토리에 있는 라이브러리를 사용하는 동안 시스템에 설치된 kdb 라이브러리를 사용하고 있습니다. 최소한 LUA_CPATH 설정해야 합니다. https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/swig/lua/tests/CMakeLists.txt#L12 참조

swig 관련 충돌의 90%는 빌드 환경 결함과 관련이 있습니다. 따라서 먼저 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의 빌드 시스템 문제입니다. 나는 전자를 의심한다. 핑 @markus2330

dlopen(libelektra-resolver.so, 2): image not found 실제로 lua와 아무 관련이 없는 것처럼 보입니다.

libelektra-resolver.so 는 KDB_DEFAULT_RESOLVER 선택한 리졸버에 대한 심볼릭 링크여야 합니다. 설정/설치가 손상되었을 수 있습니까? 심볼릭 링크가 올바른지 확인할 수 있습니까?

이상한 점은: libelektra-resolver.so 가 모든 kdb 관련 테스트 케이스에서 사용되는데, 왜 이 테스트 케이스에서만 작동 _하지_합니까? 아마도 이 테스트 케이스(그리고 파이썬 케이스)는 빌드 디렉토리의 라이브러리가 아닌 설치된 라이브러리를 사용합니다. 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 - dtruss Output.txt . 테스트에서 빌드 디렉토리의 Elektra 버전을 사용하는 것 같습니다. sudo ninja uninstall 를 통해 Elektra를 제거했습니다. 그런 다음 테스트를 다시 실행했습니다. 출력은 여전히 ​​동일합니다.

팻 바이너리를 사용합니까?

제가 알고 있는 것은 아닙니다.

OSX El Capitan을 사용합니까? 이상한 시스템 무결성 보호 문제 일 수 있습니다.

그래도 kdb 작동한다는 것은 좀 이상합니다.

python/lua 설치로 인해 시스템 무결성 보호와 관련이 있는 경우 의미가 있을 수 있습니다.

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 여전히 실패하지만 Elektra 0.8.16이 출시되었을 때 최소한 testscr_check_kdb_internal_suite 작동했다는 것을 기억합니다. 다음은 현재 실패한 추가 테스트의 출력입니다.
testcr_check_kdb_internal_suite.txt
testcr_check_merge.txt

제목을 변경하고 삭제했습니다. 나는 OSX 머신에 직접 접근할 수 없고 깊이 있는 지식이 부족합니다. 주변을 찌르는 기계가 없으면 텍스트 출력에서 ​​아무것도 말할 수 없습니다.

링크의 다른 힌트도 보셨나요? 예를 들어 python/lua를 다시 설치하시겠습니까?

@petermax2 @mpranj 이 문제를 재현할 수 있습니까?

링크의 다른 힌트도 보셨나요? 예를 들어 python/lua를 다시 설치하시겠습니까?

죄송합니다. Python 2 설치는 시스템과 함께 제공된 것입니다. 다시 설치하려면 전체 운영 체제를 다시 설치해야 합니다.

Lua Elektra 플러그인을 테스트하기 위해 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 없는 시스템(예: musl을 libc로 사용하는 openwrt)도 지원합니다.

FreeBSD btw에서도 비슷한 일이 일어나는 것 같습니다.

 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 디렉토리가 검색됩니다(순서대로).

man dlopen OSX:

경로에 슬래시 문자가 포함되지 않은 경우(즉, 리프 이름인 경우) dlopen()은 호환되는 Mach-O 파일을 찾을 때까지 $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, 현재 작업 디렉토리, $DYLD_FALLBACK_LIBRARY_PATH를 검색합니다.

dlopen은 여기에서 절대 경로와 함께 작동하거나 위에서 언급한 경로 중 하나에 있어야 합니다.

하지만 절대 경로는 하지 않습니다. 따라서 이 정보가 어떻게 도움이 되는지 모름

절대 RPATH 또는 플러그인에 대한 절대 경로? CMake는 빌드 트리 RPATH를 지원한다고 주장하므로 필요한 경우 절대 RPATH를 사용해야 합니다.

플러그인에 대한 절대 경로는 많은 사람들이 하는 일이며 쉽게 변경할 수 있지만 빌드 내 테스트 사례에 어떻게 도움이 되지 않을지 모르겠습니다.

먼저 여기에 실제 문제가 무엇인지 흥미로울 것입니다. 설치된 버전이 정말 완벽하게 작동합니까? 예를 들어 kdb run_all 도 흥미로울 것입니다(이미 위에서 쓴 내용 옆에 있음).

dlopen 맨페이지의 붙여넣기에 문제가 무엇인지 명확하게 나와 있습니다.
dlopen(libelektra-resolver.so)의 검색 경로는 플랫폼마다 다릅니다. dlopen이 libelektra-kdb.so의 DT_RPATH를 존중하기 때문에 Linux가 작동합니다.

LD_LIBRARY_PATH 를 설정하는 것도 밸브가 하는 일인 것 같습니다.
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 를 로드하는 라이브러리입니다. runtimelib 디렉토리로 설정된 DT_RPATH가 있습니다. (예: 바인딩의 kdb.so)
• runner ... 런타임에 dlopen 사용하여 lib 를 로드하는 실행 파일(예: lua/python)

https://gist.github.com/manuelm/43a4fa9dd424b4dcf03bd1d773a0e122 참조

이 시나리오는 Linux에서 작동하지만 FreeBSD에서는 실패합니다.

라이브러리에 설정된 RPATH가 이식 가능하지 않다는 것을 알고 있습니다(musl에서도 작동하지 않음). 그러나 그것은 Mac OS X에서 작동하는 것 같았습니다( @mpranj 는 testkdb* 테스트가 잘 작동 한다고 보고했고 kdb 이 Mac OS X에서 작동 한다고 보고했습니다). 따라서 파이썬/루아 테스트만 실패하는 이유를 조사해 달라고 요청했습니다.

Elektra를 설치하는 이식 가능한 방법은 TARGET_PLUGIN_FOLDER 설정하지 않고 테스트를 위해 (제안된 대로) LD_LIBRARY_PATH 사용할 수 있습니다. (run_memcheck 및 run_all 내에서만 설정하면 됩니다.)

@mpranj 는 또한 testkdb* 테스트가 잘 작동하고 @omnidan 이 kdb가 Mac OS X에서 작동

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를 사용하지 마십시오.

"Don't grep output, that is short, or 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 위키 에 따르면 otool -l <file> | grep LC_RPATH -A2 명령은 일부 파일의 RPATH를 표시하는 한 가지 가능한 방법입니다. 나는 내가 사용한 덜 멋진 버전인 otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH 도 어느 정도 괜찮을 것이라고 생각합니다.

얘들아 왜 이걸 아예 확인하지?

@sanssecours 죄송합니다 제가

나는 의존성을 보여주고 @rpath 만 표시하는 otool -L 을 언급하고 있었습니다. 하지만 네 맞습니다. otool -l 는 올바른 명령입니다.

Btw 내 시스템에서 elektra를 제외하고 RPATH를 사용하는 단일 라이브러리를 찾지 못했습니다.

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

@manuelm이 말했듯이 이러한 검사는 다소 무의미할 수 있습니다...

나는 우리가 위의 모든 문제를 완전히 이해했다고 생각하지 않지만 우리가 수행하는 원격 디버깅이 효율적이지 않다는 데 동의합니다. 누군가는 non-glibc 시스템을 지원하는 가장 좋은 방법을 조사하고 문서화해야 합니다. 회의에서 어떻게 진행해야 하는지 논의합시다.

@markus2330 문제를 충분히 이해합니다. 테스트가 시작되기 전에 LD_LIBRARY_PATH를 설정하면 문제가 사라집니다.

언급된 다른 모든 문제는 청어이거나 잘못된 것입니다.

@manuelm 나는 친절하고 싶었고 "우리"라고 말했다. 분명히 LD_LIBRARY_PATH는 빌드 디렉토리에서 라이브러리를 찾지 못하는 문제를 해결할 것입니다. 그러나 RPATH가 바이너리에 설정되어야 한다는 이론이 맞다면 설치된 버전도 손상될 수 있으며 이는 현재 실제로 확인되지 않았습니다. 이것은 조사되어야 합니다.

내 이론은 더 이상 이론이 아닙니다. 증명을 했기 때문입니다.

다시 한 번: Linux에서는 바인딩을 구현하는 라이브러리(lua/python의 경우 kdb.so 및 glib의 경우 libgelektra-4.0.so )에 DT_RPATH 가 _AND_ dlopen 설정되어 있기 때문에 바인딩이 작동합니다 libgelektra-4.0.so 이것을 존경합니다.

물론 바인딩은 elektra가 전역 시스템 라이브러리 경로에 설치된 후에 작동합니다. 나는 이것이 갑자기 작동을 멈추어야 할 이유를 전혀 알지 못합니다.

바인딩 테스트는 !=linux에서 작동하지 않습니다. 그게 다야.

추신: GI 바인딩 테스트에 LD_LIBRARY_PATH가 필요하다는 것을 알고 있습니다. 그렇기 때문에 GI 사례를 통합/추가하는 일종의 빌드 시스템 매크로를 추가하기를 원했습니다.

바인딩 테스트가 LD_LIBRARY_PATH가 필요한 유일한 곳인 것 같아서 거기에 추가했습니다.

@mpranj 작동 여부를 확인할 수 있는 트래비스를 곧 얻을 수 있기를 바랍니다.

@markus2330 아니요 작동하지 않습니다. (travis도 내 컴퓨터도 아님)

@mpranj 테스트

@markus2330 예 현재 travis에서 테스트 중이지만 대부분 내 컴퓨터에서와 동일한 동작을 합니다. da243f9e25d8fa14f8286c48b4338a73c1e7242d는 아무런 차이가 없는 것 같습니다.

https://travis-ci.org/mpranj/libelektra에서 볼 수 있습니다.
그리고 btw @manuelm 은 travis+OS X로 거의 완료된 것 같습니다. 테스트는 실패했지만 travis는 실제로 거의 완전히 설정되었습니다.

예, 그는 말했습니다. 주로 하나의 travis 파일로 Mac OS X 및 기타를 구축하기 위한 매트릭스 설정이 누락되었습니다.

도움을 주셔서 감사합니다. 이제 문제가 해결되어야 합니다.