Libelektra: Alguns testes falham no OS X

Sinto muito, mas não tenho o OS X. No entanto, ctest -V é seu amigo.

btw chamar lua $file não é o mesmo que executar os testes. Você está usando a biblioteca kdb instalada pelo sistema enquanto os testes obviamente usam a biblioteca localizada no diretório de compilação. Você deve definir pelo menos LUA_CPATH . consulte https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/swig/lua/tests/CMakeLists.txt#L12

90% das falhas relacionadas ao swig foram relacionadas a falhas no ambiente de construção. Portanto, primeiro tente regenerar (!) + Recompilar as ligações do swig.

Esse problema pode estar relacionado ao ad537b3 (pelo menos no Linux kdb * lua | python estavam travando, mas a correção para Linux faz parte do ad537b3). Sem a saída do teste, não se pode realmente dizer.

Você pode usar make run_all que suprime a saída de casos de teste bem-sucedidos, mas mostra a saída para os que falharam.

@sanssecours Alguma atualização sobre isso?

Esse problema pode estar relacionado ao ad537b3 (pelo menos no Linux kdb * lua | python estavam travando, mas a correção para Linux faz parte do ad537b3). Sem a saída do teste, não se pode realmente dizer.

@sanssecours Alguma atualização sobre isso?

Desculpe pela resposta tardia. Achei que já tivesse escrito um comentário contendo informações estendidas sobre esse assunto. Deixe-me começar dizendo que testpy2_kdb.py também falha em minha máquina. Portanto, pode ser um problema com minha configuração específica. Eu instalei o SWIG via Homebrew e atualmente uso o seguinte comando cmake para gerar os arquivos de compilação para Elektra:

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

Aqui está o resultado de 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

Parece que Lua não conseguiu encontrar libelektra-resolver.so , que está localizado em build/lib e /usr/local/lib/elektra na minha máquina. Preciso definir algum caminho de biblioteca para que isso funcione? A propósito, parece que testpy2_kdb.py também falha devido ao mesmo problema.

As ligações não carregam nenhuma biblioteca elektra em tempo de execução. Eles são apenas ligações. Você pode ver isso observando a localização exata do erro, que é ../src/libs/loader/dl.c:82 .

Portanto, este é um problema com o seu ambiente, um problema geral de elektra no OSX ou um problema de construção do sistema no OSX. Eu suspeito do primeiro. ping @ markus2330

dlopen(libelektra-resolver.so, 2): image not found realmente parece que não tem nada a ver com lua.

libelektra-resolver.so deve ser um link simbólico para o resolvedor que você selecionou com KDB_DEFAULT_RESOLVER , talvez sua configuração / instalação esteja corrompida? Você pode verificar se os links simbólicos estão corretos?

O estranho é: libelektra-resolver.so é usado em todos os casos de teste relacionados ao kdb, por que apenas _não_ está funcionando neste caso de teste? Talvez este caso de teste (e o do python) use a biblioteca instalada e não a biblioteca no diretório de construção. Você pode verificar com strace qual libelektra-resolver.so o caso de teste tenta carregar?

image not found é bastante genérico, pode ser que dentro da biblioteca a imagem para a sua arquitetura não seja encontrada? Você usa binários de gordura ?

libelektra-resolver.so deve ser um link simbólico para o resolvedor que você selecionou com KDB_DEFAULT_RESOLVER , talvez sua configuração / instalação esteja quebrada?

Existe uma maneira fácil de verificar se a instalação local da Elektra está quebrada? O comando kdb parece funcionar.

Você pode verificar se os links simbólicos estão corretos?

Ambos os libelektra-resolver.so aliases são vinculados a um arquivo libelektra-resolver_fm_hpu_b.so localizado no mesmo diretório dos apelidos. Portanto, parece que eles estão corretos.

Você pode verificar com strace qual libelektra-resolver.so o caso de teste tenta carregar?

Tentei sudo dtruss ctest -V -R test_kdb.lua . Aqui está o resultado:
test_kdb.lua - dtruss Output.txt . Parece que o teste usa a versão Elektra no diretório de construção. Desinstalei o Elektra por meio de sudo ninja uninstall . Em seguida, executei o teste novamente. A saída ainda é a mesma.

Você usa binários de gordura?

Não que eu saiba.

Você usa OSX El Capitan? Pode ser um problema estranho de proteção de integridade do sistema .

É meio estranho que kdb funcione.

Se tiver a ver com uma Proteção de Integridade do Sistema por causa da instalação do python / lua, pode fazer sentido.

Você usa OSX El Capitan? Pode ser um problema estranho de proteção de integridade do sistema.

Sim, eu uso o OS X 10.11.4. Desativei o SIP temporariamente e executei o teste novamente. Ainda é o mesmo problema. Embora, depois de desabilitar o SIP, encontrei um novo teste que falhou: testscr_check_kdb_internal_suite . E agora testscr_check_merge também não funciona mais 😢.

Voltei para 0.8.16, limpei meu diretório de compilação e executei ninja test novamente. Tanto testscr_check_kdb_internal_suite quanto testscr_check_merge ainda falham, embora eu me lembre de que pelo menos testscr_check_kdb_internal_suite funcionava quando Elektra 0.8.16 foi lançado. Aqui está o resultado do teste adicional que também falhou agora:
testscr_check_kdb_internal_suite.txt
testscr_check_merge.txt

Eu mudei o título e me removi. Não tenho acesso direto a uma máquina OSX e carece de conhecimento aprofundado. Sem uma máquina para vasculhar, não posso dizer nada a partir da saída de texto.

Você também olhou para as outras dicas dos links? Por exemplo, reinstalando python / lua?

@ petermax2 @mpranj Você pode reproduzir esses problemas?

Você também olhou para as outras dicas dos links? Por exemplo, reinstalando python / lua?

Desculpe, na verdade não. A instalação do Python 2 é a mesma que acompanha o sistema. Para reinstalá-lo, eu teria que reinstalar todo o sistema operacional.

Instalei o Lua apenas para testar o plugin Lua Elektra. Portanto, não acho que reinstalar faça muito sentido. No entanto, como leva apenas alguns segundos, executei brew reinstall lua . Depois disso, comecei com um diretório de compilação limpo, executei os comandos de compilação e ctest -VV -R test_kdb.lua . O teste ainda mostra a mesma saída.

A propósito: os testes testscr_check_kdb_internal_suite e testscr_check_merge agora também funcionam corretamente novamente, após eu ter removido todos os arquivos de /etc/kdb .

Atualmente não tenho outra ideia. (exceto o isolamento demorado do problema: para reduzir a chamada dlopen a um exemplo mínimo onde não funcionará) Portanto, pode ser melhor esperar se alguém puder reproduzir o problema, talvez ele dê uma nova luz sobre o problema.

Posso confirmar o mesmo comportamento na minha máquina.

Solução: defina o caminho da biblioteca corretamente: por exemplo
LD_LIBRARY_PATH="/Users/mpranj/workspace/libelektra/build/lib" ctest -V -R test_kdb.lua funciona bem para mim.

dlopen nas pesquisas do OS X $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH , acho que nessa ordem.

O PR # 710 corrige isso, mas não tenho certeza se a correção é muito limpa.

Não, a correção definitivamente não é limpa.

Pelo que me lembro, nossos testes contam com DT_RPATH sendo definido em libelektra-kdb.so . Se isso não estiver disponível no OSX, devemos definir isso em algum local de ambiente de construção global.

Edit: Mas obrigado por descobrir!

RPATH é definido para todas as bibliotecas principais, mas talvez libelektra-core deva ser suficiente: neste lugar o dlopen acontece.

image not found significa simplesmente biblioteca não encontrada? Em caso afirmativo, alguma ideia de por que RPATH funciona para todos os testes, exceto lua e python?

Apenas para sua informação: Elektra também suporta sistemas sem RPATH (por exemplo, openwrt com musl como libc) simplesmente definindo TARGET_PLUGIN_FOLDER como uma string vazia.

Parece que coisas semelhantes acontecem no 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:

Ainda não consegui verificar lua no FreeBSD.

@mpranj bom saber, então FreeBSD parece ser uma boa dica se funcionar com MacOSX também (próximo ao OpenBSD). Os outros kdb testcases e a ferramenta de linha de comando kdb funcionam?

Você pode abrir questões ou anexar questões do OpenBSD sobre os casos de teste que não funcionam no FreeBSD?

Se você quer dizer estes:

        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

... então sim. A ferramenta kdb parece funcionar (apenas uma verificação rápida com ls).

Caso contrário, muitas coisas estão falhando, mas não poderei verificar / relatar tudo hoje. Mas com certeza vou relatar tudo quando for testá-lo adequadamente.

Meu palpite é que os testes de kdb funcionam porque eles estão vinculados estaticamente, certo?
Se eu desabilitar BUILD_STATIC os testes também não funcionam.

@ markus2330 Não acho que podemos evitar definir LD_LIBRARY_PATH em algumas plataformas. Como TARGET_PLUGIN_FOLDER funcionando? Ou, mais especificamente, como isso resolve a pesquisa dinâmica na biblioteca?

Obrigado, essa é uma boa ideia: @sanssecours você pode desativar BUILD_STATIC e BUILD_FULL e executar novamente todos os testes ( testkdb )?

Se TARGET_PLUGIN_FOLDER estiver vazio, os plug-ins são instalados onde as bibliotecas estão e nenhum RPATH ou LD_LIBRARY_PATH é necessário. Mas isso só ajudaria quando o Elektra instalado fosse usado (o que pode ser o caso dos testes python / lua ).

https://cmake.org/Wiki/CMake_RPATH_handling diz ".. RPATH no Mac OS X. Será habilitado tanto para a árvore de construção quanto para a árvore de instalação", então, na verdade, também os binários da árvore de construção devem ter RPATH definido. @sanssecours Você pode verificar isso? Por exemplo, usando readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

O problema não é sobre o RPATH em si, mas sobre dlopen no linux lendo DT_RPATH em comparação com outras plataformas.

man dlopen da glibc:

• (ELF apenas) Se o arquivo executável do programa de chamada contiver uma marca DT_RPATH e não contiver uma marca DT_RUNPATH, os diretórios listados na marca DT_RPATH serão pesquisados.
• Se, no momento em que o programa foi iniciado, a variável de ambiente LD_LIBRARY_PATH foi definida para conter uma lista de diretórios separados por dois pontos, então eles serão pesquisados. (Como medida de segurança, esta variável é ignorada para os programas set-user-ID e set-group-ID.)
• (ELF apenas) Se o arquivo executável do programa de chamada contiver uma tag DT_RUNPATH, os diretórios listados nessa tag serão pesquisados.
• O arquivo de cache /etc/ld.so.cache (mantido por ldconfig (8)) é verificado para ver se ele contém uma entrada para nome de arquivo.
• Os diretórios / lib e / usr / lib são pesquisados ​​(nessa ordem).

man dlopen no OSX:

Quando o caminho não contém um caractere de barra (ou seja, é apenas um nome de folha), dlopen () pesquisa o seguinte até encontrar um arquivo Mach-O compatível: $ LD_LIBRARY_PATH, $ DYLD_LIBRARY_PATH, diretório de trabalho atual, $ DYLD_FALLBACK_LIBRARY_PATH.

dlopen deve funcionar com caminhos absolutos aqui, ou precisa estar em um dos caminhos mencionados acima

Mas não fazemos caminhos absolutos. Portanto, não tenho ideia de como essa informação ajuda

RPATH absoluto ou caminhos absolutos para plug-ins? CMake afirma que tem suporte para RPATH de árvore de construção, então ele deve usar um RPATH absoluto se necessário.

Caminhos absolutos para plug-ins é o que muitos fazem e seria uma mudança fácil, mas não vejo como isso não ajudaria nos casos de teste internos.

Em primeiro lugar, seria interessante qual é o problema real aqui. A versão instalada realmente funciona totalmente? Por exemplo, kdb run_all também seria interessante (próximo ao que já escrevi acima).

Minha pasta de dlopen manpages afirma claramente do que se trata.
O caminho de pesquisa de dlopen (libelektra-resolver.so) é diferente em plataformas diferentes. Linux funciona porque dlopen honra DT_RPATH do libelektra-kdb.so

Parece que definir LD_LIBRARY_PATH é o que a válvula também está fazendo.
https://github.com/ValveSoftware/steam-runtime/blob/master/runtime/run.sh

Quer dizer que o problema é que eles não escrevem documentação? @rpath nem sequer é mencionado aqui.

Acho que até que não saibamos o que realmente funciona quando instalado / com BUILD_SHARED não devemos especular mais.

@ markus2330
EDIT: desabilitando BUILD_STATIC e BUILD_FULL:
os testes testkdb * funcionam bem.

Sobre a documentação, eles mencionam @rpath aqui .

Acabei de verificar minha declaração com um pequeno exemplo:

• runtimelib ... uma biblioteca que fornece algumas funções aleatórias. (como elektra-resolver)
• lib ... uma biblioteca que carrega runtimelib em tempo de execução usando dlopen . Ele tem DT_RPATH definido para o diretório de runtimelib . (como kdb.so das ligações)
• runner ... um executável que carrega lib em tempo de execução usando dlopen (como lua / python)

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

Este cenário funciona no Linux, mas falha no FreeBSD.

Eu sei que RPATH definido em uma biblioteca não é portátil (também não funcionou para musl). Mas parecia funcionar para Mac OS X ( @mpranj também relatou que os testes testkdb * funcionam bem e @omnidan relatou que kdb funciona com Mac OS X). Assim, pedi para investigar por que apenas os testes python / lua falham.

A maneira portátil de instalar o Elektra não está configurando TARGET_PLUGIN_FOLDER e para os testes poderíamos usar (como sugerido) LD_LIBRARY_PATH . (Só precisaríamos defini-lo em run_memcheck e run_all).

@mpranj também relatou que os testes testkdb * funcionam bem e @omnidan relatou que o kdb funciona com Mac OS X

testkdb* e kdb definiram DT_RPATH automaticamente. O interpretador Python e lua não. Isso é fundamentalmente diferente.

[...] e para testes poderíamos usar (como sugerido) LD_LIBRARY_PATH.

Então, por favor, adicione. Obrigado

Sim, você está certo para o sistema de construção: CMake parece definir RPATH em todos os executáveis, mas obviamente não para python / lua.

Quando instalado, no entanto, ele não seria definido. Então, por favor, alguém confirme se kdb funciona (com TARGET_PLUGIN_FOLDER definido).

@sanssecours você pode desativar BUILD_STATIC e BUILD_FULL e executar novamente todos os testes ( testkdb )?

Parece que isso não muda muito, exceto que ninja test executa menos testes (54 em vez de 114). Os testes test_kdb.lua e testpy2_kdb.py ainda falham. Todos os outros testes (parecem) funcionar.

https://cmake.org/Wiki/CMake_RPATH_handling diz ".. RPATH no Mac OS X. Será habilitado tanto para a árvore de construção quanto para a árvore de instalação", então, na verdade, também os binários da árvore de construção devem ter RPATH definido. Por exemplo, usando readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

Usei o comando otool -l lib/libelektra-resolver.so - libelektra-core.so.0.8.16 não existe na minha máquina. De acordo com o resultado:

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

RPATH está definido.

Por exemplo, kdb run_all também seria interessante (próximo ao que já escrevi acima).

Na minha máquina, 5 de 655 testes falharam. 4 dos testes ( testmod_crypto , testmod_iterate , testmod_semlock e testmod_template ) falham devido ao mesmo erro básico:

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

O teste testmod_python2 mostra a seguinte saída de erro:

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

Abaixo está a saída de testmod_lua , que não relata erros.

--- 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).

No OS X, dylibs são criados, não .so. Definitivamente, há um libelektra-core.0.8.16.dylib ou similar.

Definitivamente, há um libelektra-core.0.8.16.dylib ou similar.

Você está certo. Parece que RPATH não está definido para libelektra-core.0.8.16.dylib , pois otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH não exibe nenhuma saída.

A saída do grep é curta, ou grep rpath minúsculo

A saída do grep é curta, ou grep rpath minúsculo

Você quer dizer “Não execute grep na saída, isso é curto, ou grep rpath minúsculo”? Se sim, por que não? Também pesquisei RPATH na saída de otool -l lib/libelektra-core.0.8.16.dylib por meio da pesquisa integrada de meu aplicativo Terminal. Isso também não mostra nenhuma ocorrência de LC_RPATH .

Se eu pesquisar rpath , vejo uma ocorrência de @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
...

Pelo que eu sei, @rpath é apenas um espaço reservado para (os valores armazenados em) RPATH . Não acho que esta ocorrência de rpath nos diga se RPATH está definido ou não.

De acordo com o wiki CMake, o comando otool -l <file> | grep LC_RPATH -A2 é uma forma possível de mostrar os RPATHs de algum arquivo. Acho que a versão menos sofisticada que usei - otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH - deve ser mais ou menos boa também.

Gente, por que você está verificando isso?

@sanssecours desculpe, enviei a mensagem rapidamente do meu telefone, então não vi que não fazia sentido.

Eu estava me referindo a otool -L que mostra as dependências e exibe apenas @rpath . Mas sim, você está certo otool -l é o comando certo.

Btw eu não encontrei uma única biblioteca em meu sistema que está usando RPATH, exceto elektra.

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

Como @manuelm afirma, porém, essas verificações podem ser um tanto inúteis ...

Acho que não entendemos totalmente todos os problemas acima, mas concordo que o tipo de depuração remota que estamos fazendo não é eficiente. Alguém deve investigar e documentar qual é a melhor maneira de oferecer suporte a sistemas não-glibc. Vamos discutir na reunião como proceder.

@ markus2330 Compreendo perfeitamente o problema. Defina LD_LIBRARY_PATH antes do início dos testes e eu prometo que o problema foi resolvido.

Todos os outros problemas mencionados são pistas falsas ou simplesmente erradas.

@manuelm Eu queria ser legal e disse "nós". Obviamente, o LD_LIBRARY_PATH resolveria os problemas de não encontrar bibliotecas no diretório de construção (a menos que seja redefinido em algum lugar, o que parece ser o caso pelo menos para testes de GI python / lua). Mas se sua teoria estiver correta de que RPATH deve ser definido no binário, também a versão instalada seria quebrada, o que atualmente não está realmente confirmado. Isso deve ser investigado.

Minha teoria não é mais apenas uma teoria, porque eu fiz a prova.

Mais uma vez: No Linux as ligações funcionam porque a biblioteca que as implementa ( kdb.so para lua / python e libgelektra-4.0.so para glib) tem DT_RPATH set _AND_ dlopen honra isso.

É claro que as ligações funcionarão após a instalação do elektra nos caminhos da biblioteca global do sistema. Não vejo absolutamente nenhuma razão para que isso pare de funcionar de repente.

Os testes das ligações não funcionam para! = Linux. Isso é tudo.

PS: Eu sei que os testes de ligação de GI requerem LD_LIBRARY_PATH. É por isso que eu queria que você adicionasse algum tipo de macro de sistema de construção que integre / acrescente o caso GI.

Parece que os testes de ligação são o único lugar onde o LD_LIBRARY_PATH é necessário, então eu o adicionei lá.

@mpranj Espero que em breve tenhamos um travis que possa confirmar se funciona?

@ markus2330 não, não funciona. (nem no travis nem na minha máquina)

@mpranj obrigado pelo teste. Você tem o arquivo travis pronto para testá-lo novamente sem incomodar ninguém? Ambos os casos de teste ainda falham? Eu esqueci LD_LIBRARY_PATH em algum lugar ou a abordagem simplesmente não está funcionando?

@ markus2330 sim, atualmente estou testando em travis, mas tem praticamente o mesmo comportamento que em minha máquina. Parece que da243f9e25d8fa14f8286c48b4338a73c1e7242d não fez diferença.

Você pode ver aqui: https://travis-ci.org/mpranj/libelektra
E aliás , parece que

Sim, ele disse isso. Principalmente a configuração da matriz para construir o Mac OS X e outros com um arquivo travis estava faltando.

Obrigado por toda a sua ajuda, o problema deve ser corrigido agora.