Libelektra: Некоторые тесты терпят неудачу в OS X

Извините, но у меня нет 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% сбоев, связанных с swig, были связаны с ошибками среды сборки. Так что сначала попробуйте регенерировать (!) + Перекомпилировать привязки swig.

Эта проблема может быть связана с ad537b3 (по крайней мере, в Linux происходили сбои kdb * lua | python, но исправление для Linux является частью ad537b3). Без вывода теста ничего толком не сказать.

Вы можете использовать make run_all который подавляет вывод успешных тестовых случаев, но показывает вывод для неудачных.

@sanssecours Есть поводу ?

Эта проблема может быть связана с ad537b3 (по крайней мере, в Linux происходили сбои kdb * lua | python, но исправление для Linux является частью ad537b3). Без вывода теста ничего толком не сказать.

@sanssecours Есть поводу ?

Извините за поздний ответ. Я думал, что уже написал комментарий, содержащий расширенную информацию по этой проблеме. Позвольте мне начать с того, что testpy2_kdb.py также не работает на моей машине. Так что это может быть проблема с моей конкретной настройкой. Я установил SWIG через Homebrew и в настоящее время использую следующую команду 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 тоже не работает из-за той же самой проблемы.

Привязки не загружают никакую библиотеку elektra во время выполнения. Это просто привязки. Вы можете убедиться в этом, посмотрев на точное место ошибки: ../src/libs/loader/dl.c:82 .

Так что это либо проблема с вашей средой, либо общая проблема elektra в OSX, либо проблема системы сборки в OSX. Я подозреваю первое. пинг @ markus2330

dlopen(libelektra-resolver.so, 2): image not found самом деле выглядит так, будто не имеет ничего общего с lua.

libelektra-resolver.so должен быть символической ссылкой на преобразователь, который вы выбрали с помощью KDB_DEFAULT_RESOLVER , возможно, ваша установка / установка не работает? Можете ли вы проверить правильность символических ссылок?

Странно: libelektra-resolver.so используется в каждом тестовом примере, связанном с kdb, почему он _не_ работает только в этом тестовом примере? Возможно, этот тестовый пример (и тот, что на Python) использует установленную библиотеку, а не библиотеку в каталоге сборки. Можете ли вы проверить с помощью strace, какой libelektra-resolver.so тестовый пример пытается загрузить?

image not found является довольно общим, может быть, в библиотеке не найдено изображение для вашей архитектуры? Вы используете толстые двоичные файлы ?

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 Output.txt . Похоже, что тест использует версию Elektra в каталоге сборки. Я удалил Электру через sudo ninja uninstall . Затем я снова запустил тест. Результат все тот же.

Вы используете толстые двоичные файлы?

Не то, чтобы я знаю.

Вы используете 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 прежнему не работают, хотя я помнил, что, по крайней мере, testscr_check_kdb_internal_suite работали, когда была выпущена Elektra 0.8.16. Вот результат дополнительного теста, который тоже не прошел:
testscr_check_kdb_internal_suite.txt
testscr_check_merge.txt

Я изменил название и удалился. У меня нет прямого доступа к машине OSX и мне не хватает глубоких знаний. Без машины я ничего не могу сказать по тексту.

Вы также смотрели другие подсказки по ссылкам? Например, переустановка python / lua?

@ petermax2 @mpranj Можете ли вы воспроизвести эти проблемы?

Вы также смотрели другие подсказки по ссылкам? Например, переустановка python / lua?

Извини, не совсем. Установка Python 2 - это та самая установка, которая идет в комплекте с системой. Чтобы переустановить его, мне пришлось бы переустановить всю операционную систему.

Я установил Lua только для того, чтобы протестировать плагин Lua Elektra. Так что я не думаю, что переустановка имеет большой смысл. Однако, поскольку это занимает всего несколько секунд, я выполнил brew reinstall lua . После этого я начал с чистого каталога сборки, выполнил команды сборки и ctest -VV -R test_kdb.lua . Тест по-прежнему показывает тот же результат.

Кстати: тесты testscr_check_kdb_internal_suite и testscr_check_merge теперь снова работают правильно, после того как я удалил все файлы из /etc/kdb .

В настоящее время у меня нет другой идеи. (за исключением трудоемкой изоляции проблемы: чтобы сократить вызов dlopen до минимального примера, где он не будет работать) Так что, возможно, лучше подождать, если кто-то сможет воспроизвести проблему, возможно, это проливает новый свет на проблему.

Я могу подтвердить то же поведение на своей машине.

Решение: правильно укажите путь к библиотеке: например
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 исправляет это, однако я не уверен, что исправление очень чистое.

Нет, исправление точно не чистое.

Насколько я помню, наши тесты полагаются на то, что DT_RPATH установлено в libelektra-kdb.so . Если это недоступно в OSX, мы должны определить это в некотором месте глобальной среды сборки.

Изменить: Но спасибо, что узнали!

RPATH установлен для всех основных библиотек, но, возможно, libelektra-core должно хватить: в этом месте происходит dlopen .

image not found просто означает, что библиотека не найдена? Если да, то есть идеи, почему RPATH работает для всех, кроме тестов lua и python?

Для информации: Elektra также поддерживает системы без RPATH (например, openwrt с musl как libc), просто установив TARGET_PLUGIN_FOLDER в пустую строку.

Похоже, что подобные вещи случаются и с 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:

Пока не удалось проверить lua на FreeBSD.

@mpranj полезно знать, поэтому FreeBSD кажется хорошим советом, если она работает и с MacOSX (рядом с OpenBSD). Работают ли другие тестовые сценарии kdb и инструмент командной строки kdb ?

Можете ли вы открывать вопросы или добавлять в OpenBSD вопросы о тестовых примерах, которые не работают во FreeBSD?

Если вы имеете в виду эти:

        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 говорит: «.. RPATH в Mac OS X. Он будет включен как для дерева сборки, так и для дерева установки», поэтому на самом деле также для двоичных файлов дерева сборки должен быть установлен RPATH. @sanssecours Вы можете это проверить? Например, используя readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

Проблема не в самом RPATH, а в том, что dlopen на Linux, читающем 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.

dlopen должен работать с абсолютными путями здесь, или он должен быть на одном из путей, упомянутых выше

Но мы не идем абсолютными путями. Так что не знаю, как эта информация помогает

Абсолютный RPATH или абсолютные пути к плагинам? CMake утверждает, что поддерживает RPATH дерева построения, поэтому при необходимости следует использовать абсолютный RPATH.

Абсолютные пути к плагинам - это то, что многие делают, и это было бы легко изменить, но я не понимаю, как это не поможет для тестовых примеров во время сборки.

Сначала было бы интересно, в чем здесь настоящая проблема. Установленная версия действительно полноценно работает? Например, kdb run_all тоже было бы интересно (рядом с тем, что я уже писал выше).

Моя паста из dlopen manpages четко указывает, в чем проблема.
Путь поиска dlopen (libelektra-resolver.so) отличается на разных платформах. Linux работает, потому что dlopen соблюдает DT_RPATH файла libelektra-kdb.so

Кажется, что установка 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 ... библиотека, предоставляющая некоторые случайные функции. (как электра-резольвер)
• lib ... библиотека, которая загружает runtimelib во время выполнения, используя dlopen . Он имеет DT_RPATH, установленный в каталог runtimelib . (как kdb.so привязок)
• runner ... исполняемый файл, который загружает lib во время выполнения с использованием dlopen (например, lua / python)

См. Https://gist.github.com/manuelm/43a4fa9dd424b4dcf03bd1d773a0e122

Этот сценарий работает в Linux, но не работает во FreeBSD.

Я знаю, что 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).

@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 выполняет меньше тестов (54 вместо 114). Тесты test_kdb.lua и testpy2_kdb.py прежнему терпят неудачу. Все остальные тесты (кажется) работают.

https://cmake.org/Wiki/CMake_RPATH_handling говорит: «.. RPATH в Mac OS X. Он будет включен как для дерева сборки, так и для дерева установки», поэтому на самом деле также для двоичных файлов дерева сборки должен быть установлен 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 тоже был бы интересен (рядом с тем, что я уже писал выше).

На моей машине 5 из 655 тестов не прошли. 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. Определенно есть libelektra-core.0.8.16.dylib или аналогичный.

Определенно есть libelektra-core.0.8.16.dylib или аналогичный.

Ты прав. Похоже, что RPATH не задано для libelektra-core.0.8.16.dylib , поскольку otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH выводит никаких результатов.

Не выводите grep или grep в нижнем регистре rpath

Не выводите grep или grep в нижнем регистре rpath

Вы имеете в виду «Не выводить grep, это короткий или grep в нижнем регистре rpath»? Если да, то почему бы и нет? Я также искал RPATH в выводе otool -l lib/libelektra-core.0.8.16.dylib через встроенный поиск моего приложения Terminal. Это также показывает отсутствие появления 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 извините, я быстро отправил сообщение со своего телефона, поэтому не

Я имел в виду otool -L который показывает зависимости и отображает только @rpath . Но да, вы правы, otool -l - правильная команда.

Кстати, я не нашел ни одной библиотеки в своей системе, которая использует RPATH, кроме elektra.

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

Однако, как утверждает

Я не думаю, что мы полностью понимаем все вышеперечисленные проблемы, но я согласен с тем, что применяемая нами удаленная отладка неэффективна. Кто-то должен исследовать и задокументировать, как лучше всего поддерживать системы, отличные от glibc. Давайте обсудим на встрече, как действовать дальше.

@ markus2330 Я полностью понимаю

Все остальные упомянутые проблемы - отвлекающий маневр или просто неправильные.

@manuelm Я хотел быть милым и сказал «мы». Очевидно, что LD_LIBRARY_PATH исправит проблемы, связанные с отсутствием поиска библиотек в каталоге сборки (если он где-то не сброшен, что, по-видимому, имеет место, по крайней мере, для тестов python / lua GI). Но если ваша теория верна, что RPATH должен быть установлен в двоичном файле, то установленная версия также будет повреждена, что в настоящее время действительно не подтверждено. Это должно быть исследовано.

Моя теория больше не просто теория, потому что я сделал доказательство.

Еще раз: в Linux привязки работают, потому что библиотека, реализующая привязки ( kdb.so для lua / python и libgelektra-4.0.so для glib), имеет DT_RPATH set _AND_ dlopen чтит это.

Конечно, привязки будут работать после того, как elektra будет установлен в пути глобальных системных библиотек. Я абсолютно не вижу причин, почему это должно внезапно перестать работать.

Тесты привязок не работают для! = Linux. Это все.

PS: Я знаю, что тесты привязки GI требуют LD_LIBRARY_PATH. Вот почему я хотел, чтобы вы добавили какой-то макрос системы сборки, который объединяет / дополняет случай GI.

Кажется, что тесты привязки - единственное место, где требуется LD_LIBRARY_PATH, поэтому я добавил его прямо там.

@mpranj Надеюсь, скоро мы получим трэвис, который подтвердит, работает ли это?

@ markus2330 нет, это не работает. (ни на Трэвисе, ни на моей машине)

@mpranj спасибо за тестирование. У вас есть готовый файл travis, чтобы протестировать его еще раз, никого не беспокоя? Оба тестовых примера по-прежнему не работают? Я где-то забыл LD_LIBRARY_PATH или подход просто не работает?

@ markus2330 да, в настоящее время я тестирую Travis, но он в основном ведет себя так же, как и на моей машине. Похоже, что da243f9e25d8fa14f8286c48b4338a73c1e7242d не имело никакого значения.

Вы можете увидеть это здесь: https://travis-ci.org/mpranj/libelektra
И, кстати, похоже, что @manuelm в значительной степени реализован с помощью travis + OS X. Тесты не работают, но на самом деле Travis почти полностью настроен, я думаю.

Да, он это сказал. В основном отсутствовала настройка матрицы для сборки Mac OS X и других с одним файлом travis.

Спасибо за вашу помощь, проблема должна быть исправлена.