Libelektra: Algunas pruebas fallan en OS X

Lo siento, pero no tengo OS X. Sin embargo, ctest -V es tu amigo.

Por cierto, llamar a lua $file no es lo mismo que ejecutar las pruebas. Está utilizando la biblioteca kdb instalada en el sistema, mientras que las pruebas obviamente usan la biblioteca ubicada en el directorio de compilación. Debería establecer al menos LUA_CPATH . ver https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/swig/lua/tests/CMakeLists.txt#L12

El 90% de los accidentes relacionados con tragos se relacionaron con fallas en el entorno de construcción. Así que primero intente regenerar (!) + Recompilar los enlaces de trago.

Este problema podría estar relacionado con ad537b3 (al menos en Linux, kdb * lua | python fallaba, pero la solución para Linux es parte de ad537b3). Sin el resultado de la prueba, no se puede decir realmente.

Puede usar make run_all que suprime la salida de los casos de prueba exitosos pero muestra la salida de los fallidos.

@sanssecours ¿ Alguna actualización sobre esto?

Este problema podría estar relacionado con ad537b3 (al menos en Linux, kdb * lua | python fallaba, pero la solución para Linux es parte de ad537b3). Sin el resultado de la prueba, no se puede decir realmente.

@sanssecours ¿ Alguna actualización sobre esto?

Lo siento por la respuesta tardía. Pensé que ya había escrito un comentario que contenía información ampliada sobre este problema. Permítanme comenzar diciendo que testpy2_kdb.py también falla en mi máquina. Por lo tanto, podría ser un problema con mi configuración específica. Instalé SWIG a través de Homebrew y actualmente uso el siguiente comando cmake para generar los archivos de compilación para Elektra:

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

Aquí está la salida 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 no puede encontrar libelektra-resolver.so , que se encuentra en build/lib y /usr/local/lib/elektra en mi máquina. ¿Necesito establecer alguna ruta de biblioteca para que esto funcione? Por cierto, parece que testpy2_kdb.py también falla debido al mismo problema exacto.

Los enlaces no cargan ninguna biblioteca elektra en tiempo de ejecución. Son solo ataduras. Puede ver esto mirando la ubicación exacta del error, que es ../src/libs/loader/dl.c:82 .

Entonces, esto es un problema con su entorno, un problema general de elektra en OSX o un problema del sistema de compilación en OSX. Sospecho de lo primero. ping @ markus2330

dlopen(libelektra-resolver.so, 2): image not found realidad parece que no tiene nada que ver con lua.

libelektra-resolver.so debería ser un enlace simbólico al solucionador que seleccionó con KDB_DEFAULT_RESOLVER , ¿tal vez su configuración / instalación no funciona? ¿Puede comprobar si los enlaces simbólicos son correctos?

Extraño es: libelektra-resolver.so se usa en cada caso de prueba relacionado con kdb, ¿por qué solo _no_ funciona en este caso de prueba? Quizás este caso de prueba (y el de python) use la biblioteca instalada y no la biblioteca en el directorio de compilación. ¿Puedes comprobar con strace qué libelektra-resolver.so intenta cargar el caso de prueba?

image not found es bastante genérico, ¿podría ser que dentro de la biblioteca no se encuentre la imagen de su arquitectura? ¿Utiliza binarios gordos ?

libelektra-resolver.so debería ser un enlace simbólico al solucionador que seleccionó con KDB_DEFAULT_RESOLVER , ¿tal vez su configuración / instalación no funciona?

¿Existe una manera fácil de comprobar si la instalación local de Elektra está rota? El comando kdb parece funcionar.

¿Puede comprobar si los enlaces simbólicos son correctos?

Ambos alias libelektra-resolver.so enlazan a un archivo libelektra-resolver_fm_hpu_b.so ubicado en el mismo directorio que los alias. Entonces parece que están en lo correcto.

¿Puedes comprobar con strace qué libelektra-resolver.so intenta cargar el caso de prueba?

Probé sudo dtruss ctest -V -R test_kdb.lua . Aquí está el resultado:
test_kdb.lua - dtruss Output.txt . Parece que la prueba usa la versión de Elektra en el directorio de compilación. Desinstalé Elektra a través de sudo ninja uninstall . Luego volví a ejecutar la prueba. La salida sigue siendo la misma.

¿Utiliza binarios gordos?

No que yo sepa.

¿Usas OSX El Capitan? Podría ser un problema extraño de protección de la integridad del sistema .

Sin embargo, es un poco extraño que kdb funcione.

Si tiene que ver con una protección de integridad del sistema debido a la instalación de python / lua, podría tener sentido.

¿Usas OSX El Capitan? Podría ser un problema extraño de protección de la integridad del sistema.

Sí, uso OS X 10.11.4. Inhabilité SIP temporalmente y volví a ejecutar la prueba. Sigue siendo el mismo problema. Aunque, después de deshabilitar SIP, encontré una nueva prueba que falla: testscr_check_kdb_internal_suite . Y ahora testscr_check_merge tampoco funciona más 😢.

Volví a 0.8.16, limpié mi directorio de compilación y ejecuté ninja test nuevamente. Tanto testscr_check_kdb_internal_suite como testscr_check_merge todavía fallan, aunque recordé que al menos testscr_check_kdb_internal_suite funcionó cuando se lanzó Elektra 0.8.16. Aquí está el resultado de la prueba adicional que ahora también falla:
testscr_check_kdb_internal_suite.txt
testscr_check_merge.txt

Cambié el título y me eliminé. No tengo acceso directo a una máquina OSX y no tengo un conocimiento profundo. Sin una máquina para hurgar, no puedo distinguir nada de la salida de texto.

¿También miraste las otras sugerencias de los enlaces? Por ejemplo, ¿reinstalar python / lua?

@ petermax2 @mpranj ¿Puede reproducir estos problemas?

¿También miraste las otras sugerencias de los enlaces? Por ejemplo, ¿reinstalar python / lua?

Lo siento, en realidad no. La instalación de Python 2 es la que vino con el sistema. Para reinstalarlo, tendría que reinstalar todo el sistema operativo.

Solo instalé Lua solo para probar el complemento Lua Elektra. Así que no creo que reinstalar tenga mucho sentido. Sin embargo, dado que solo toma unos segundos, ejecuté brew reinstall lua . Después de eso, comencé con un directorio de compilación limpio, ejecuté los comandos de compilación y ctest -VV -R test_kdb.lua . La prueba todavía muestra el mismo resultado.

Por cierto: las pruebas testscr_check_kdb_internal_suite y testscr_check_merge ahora también funcionan correctamente de nuevo, después de que eliminé todos los archivos de /etc/kdb .

Actualmente no tengo otra idea. (excepto el aislamiento del problema que lleva mucho tiempo: para reducir la llamada dlopen a un ejemplo mínimo en el que no funcionará). Por lo tanto, sería mejor esperar si alguien puede reproducir el problema, tal vez arroje nueva luz sobre el problema.

Puedo confirmar el mismo comportamiento en mi máquina.

Solución: establezca la ruta de la biblioteca correctamente: p. Ej.
LD_LIBRARY_PATH="/Users/mpranj/workspace/libelektra/build/lib" ctest -V -R test_kdb.lua funciona bien para mí.

dlopen en OS X busca $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH , creo que en ese orden.

El PR # 710 lo corrige, sin embargo, no estoy seguro si la solución es muy limpia.

No, la solución definitivamente no es limpia.

Por lo que recuerdo, nuestras pruebas se basan en que DT_RPATH se establezca en libelektra-kdb.so . Si esto no está disponible en OSX, deberíamos definirlo en algún lugar de entorno de construcción global.

Editar: ¡Pero gracias por descubrirlo!

RPATH está configurado para todas las bibliotecas centrales, pero tal vez libelektra-core debería ser suficiente: en este lugar ocurre el dlopen .

¿ image not found simplemente significa que no se encontró la biblioteca? Si es así, ¿alguna idea de por qué RPATH funciona para todas las pruebas excepto lua y python?

Solo para su información: Elektra también admite sistemas sin RPATH (por ejemplo, openwrt con musl como libc) simplemente configurando TARGET_PLUGIN_FOLDER en una cadena vacía.

Parece que suceden cosas similares en FreeBSD por cierto.

 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:

Todavía no he podido comprobar lua en FreeBSD.

@mpranj es bueno saberlo, por lo que FreeBSD parece ser una buena pista si también funciona con MacOSX (junto a OpenBSD). ¿Funcionan los otros casos kdb prueba kdb ?

¿Puede abrir problemas o agregar problemas de OpenBSD sobre los casos de prueba que no funcionan en FreeBSD?

Si te refieres a estos:

        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

... entonces sí. La herramienta kdb parece funcionar (solo una comprobación rápida con ls).

De lo contrario, muchas cosas están fallando, pero hoy no podré verificar / informar todo. Pero seguro que informaré de todo cuando lo pruebe correctamente.

Supongo que las pruebas de kdb funcionan porque están vinculadas estáticamente, ¿verdad?
Si desactivo BUILD_STATIC las pruebas tampoco funcionan.

@ markus2330 No creo que podamos evitar configurar LD_LIBRARY_PATH en algunas plataformas. ¿Cómo está funcionando TARGET_PLUGIN_FOLDER ? O más específico, ¿cómo resuelve esto la búsqueda dinámica de bibliotecas?

Gracias, es una buena idea: @sanssecours ¿puedes desactivar BUILD_STATIC y BUILD_FULL y volver a ejecutar todas las pruebas ( testkdb )?

Si TARGET_PLUGIN_FOLDER está vacío, los complementos se instalan donde están las bibliotecas y no se necesita RPATH o LD_LIBRARY_PATH . Pero solo ayudaría cuando se usa el Elektra instalado (que podría ser el caso de las pruebas python / lua ).

https://cmake.org/Wiki/CMake_RPATH_handling dice ".. RPATH en Mac OS X. Estará habilitado tanto para el árbol de construcción como para el árbol de instalación", por lo que en realidad también los binarios del árbol de construcción deberían tener configurado RPATH. @sanssecours ¿Puedes comprobar esto? Por ejemplo, usando readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

El problema no se trata de RPATH en sí, sino de dlopen en linux leyendo DT_RPATH frente a otras plataformas.

man dlopen de glibc:

• (Solo ELF) Si el archivo ejecutable para el programa de llamada contiene una etiqueta DT_RPATH y no contiene una etiqueta DT_RUNPATH, se buscan los directorios enumerados en la etiqueta DT_RPATH.
• Si, en el momento en que se inició el programa, la variable de entorno LD_LIBRARY_PATH se definió para contener una lista de directorios separados por dos puntos, entonces estos se buscan. (Como medida de seguridad, esta variable se ignora para los programas set-user-ID y set-group-ID).
• (Solo ELF) Si el archivo ejecutable para el programa que realiza la llamada contiene una etiqueta DT_RUNPATH, se buscan los directorios enumerados en esa etiqueta.
• Se comprueba el archivo de caché /etc/ld.so.cache (mantenido por ldconfig (8)) para ver si contiene una entrada para el nombre del archivo.
• Se buscan los directorios / lib y / usr / lib (en ese orden).

man dlopen en OSX:

Cuando la ruta no contiene un carácter de barra (es decir, es solo un nombre de hoja), dlopen () busca lo siguiente hasta encontrar un archivo Mach-O compatible: $ LD_LIBRARY_PATH, $ DYLD_LIBRARY_PATH, directorio de trabajo actual, $ DYLD_FALLBACK_LIBRARY_PATH.

dlopen debería funcionar con rutas absolutas aquí, o debe estar en una de las rutas mencionadas anteriormente

Pero no hacemos caminos absolutos. Así que no tengo idea de cómo ayuda esta información

¿RPATH absoluto o parches absolutos para complementos? CMake afirma que tiene soporte para RPATH de árbol de compilación, por lo que debería usar un RPATH absoluto si es necesario.

Los parches absolutos a los complementos es lo que muchos hacen y sería un cambio fácil, pero no veo cómo no ayudaría para los casos de prueba incorporados.

Primero, sería interesante cuál es el problema real aquí. ¿La versión instalada realmente funciona completamente? Por ejemplo, kdb run_all sería interesante (junto a lo que escribí anteriormente).

Mi pasta de las páginas de manual de dlopen indica claramente de qué se trata el problema.
La ruta de búsqueda de dlopen (libelektra-resolver.so) es diferente en diferentes plataformas. Linux funciona porque dlopen respeta DT_RPATH de libelektra-kdb.so

Parece que configurar LD_LIBRARY_PATH es lo que también está haciendo la válvula.
https://github.com/ValveSoftware/steam-runtime/blob/master/runtime/run.sh

¿Quiere decir que el problema es que no escriben documentación? @rpath ni siquiera se menciona allí.

Creo que hasta que no sepamos qué funciona realmente cuando se instala / con BUILD_SHARED no deberíamos especular más.

@ markus2330
EDITAR: deshabilitar BUILD_STATIC y BUILD_FULL:
las pruebas testkdb * funcionan bien.

Sobre la documentación, mencionan @rpath aquí .

Acabo de verificar mi declaración con un breve ejemplo:

• runtimelib ... una biblioteca que proporciona algunas funciones aleatorias. (como elektra-resolver)
• lib ... una biblioteca que carga runtimelib en tiempo de ejecución usando dlopen . Tiene DT_RPATH configurado en el directorio de runtimelib . (como kdb.so de las uniones)
• runner ... un ejecutable que carga lib en tiempo de ejecución usando dlopen (como lua / python)

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

Este escenario funciona en Linux, pero falla en FreeBSD.

Sé que RPATH establecido en una biblioteca no es portátil (tampoco funcionó para musl). Pero parecía funcionar para Mac OS X ( @mpranj también informó que las pruebas testkdb * funcionan bien y @omnidan informó que kdb funciona con Mac OS X). Por lo tanto, pedí investigar por qué solo fallan las pruebas de python / lua.

La forma portátil de instalar Elektra no es configurando TARGET_PLUGIN_FOLDER y para las pruebas podríamos usar (como se sugiere) LD_LIBRARY_PATH . (Solo necesitaríamos configurarlo dentro de run_memcheck y run_all).

@mpranj también informó que las pruebas testkdb * funcionan bien y @omnidan informó que kdb funciona con Mac OS X

testkdb* y kdb tienen DT_RPATH configurados ellos mismos. El intérprete de Python y lua no lo ha hecho. Eso es fundamentalmente diferente.

[...] y para las pruebas podríamos usar (como se sugiere) LD_LIBRARY_PATH.

Entonces por favor agréguelo. Gracias

Sí, es adecuado para el sistema de compilación: CMake parece establecer RPATH en cada ejecutable, pero obviamente no para python / lua.

Sin embargo, cuando se instala, no se configura. Entonces, por favor, alguien confirme si kdb funciona (con TARGET_PLUGIN_FOLDER set).

@sanssecours ¿puedes deshabilitar BUILD_STATIC y BUILD_FULL y volver a ejecutar todas las pruebas ( testkdb )?

Parece que esto no cambia mucho, excepto que ninja test ejecuta menos pruebas (54 en lugar de 114). Las pruebas test_kdb.lua y testpy2_kdb.py aún fallan. Todas las demás pruebas (parecen) funcionar.

https://cmake.org/Wiki/CMake_RPATH_handling dice ".. RPATH en Mac OS X. Estará habilitado tanto para el árbol de construcción como para el árbol de instalación", por lo que en realidad también los binarios del árbol de construcción deberían tener configurado RPATH. Por ejemplo, usando readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

Usé el comando otool -l lib/libelektra-resolver.so - libelektra-core.so.0.8.16 no existe en mi máquina. Según el 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á configurado.

Por ejemplo, kdb run_all también sería interesante (junto a lo que escribí anteriormente).

En mi máquina, 5 de las 655 pruebas fallan. 4 de las pruebas ( testmod_crypto , testmod_iterate , testmod_semlock y testmod_template ) fallan debido al mismo error 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

La prueba testmod_python2 muestra el siguiente resultado de error:

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

A continuación se muestra la salida de testmod_lua , que no informa errores.

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

En OS X se crean dylibs, no .so. Definitivamente hay un libelektra-core.0.8.16.dylib o similar.

Definitivamente hay un libelektra-core.0.8.16.dylib o similar.

Tienes razón. Parece que RPATH no está configurado para libelektra-core.0.8.16.dylib , ya que otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH no muestra salida.

No grep la salida es corta, o grep minúsculas rpath

No grep la salida es corta, o grep minúsculas rpath

¿Quiere decir "No grep de salida, que es corto, o grep minúsculas rpath"? Si es así, ¿por qué no? También busqué RPATH en la salida de otool -l lib/libelektra-core.0.8.16.dylib través de la búsqueda incorporada de mi aplicación Terminal. Esto tampoco muestra ninguna ocurrencia de LC_RPATH .

Si busco rpath , veo una aparición 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
...

Hasta donde yo sé, @rpath es solo un marcador de posición para (los valores almacenados en) RPATH . No creo que esta ocurrencia de rpath nos diga si RPATH está configurado o no.

Según la wiki de CMake, el comando otool -l <file> | grep LC_RPATH -A2 es una forma posible de mostrar los RPATH de algún archivo. Creo que la versión menos elegante que utilicé, otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH , también debería ser más o menos buena.

Chicos, ¿por qué están comprobando esto?

@sanssecours lo siento, envié el mensaje rápidamente desde mi teléfono, así que no vi que no tenía sentido.

Me refería a otool -L que muestra las dependencias y solo muestra @rpath . Pero sí, tienes razón otool -l es el comando correcto.

Por cierto, no he encontrado una sola biblioteca en mi sistema que esté usando RPATH, excepto elektra.

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

Sin embargo, como afirma

No creo que comprendamos completamente todos los problemas anteriores, pero estoy de acuerdo en que el tipo de depuración remota que estamos haciendo no es eficiente. Alguien debería investigar y documentar cuál es la mejor manera de admitir sistemas que no son glibc. Discutamos en la reunión cómo proceder.

@ markus2330 Entiendo completamente el problema. Configure LD_LIBRARY_PATH antes de que comiencen las pruebas y le prometo que el problema ha desaparecido.

Todos los demás problemas mencionados son pistas falsas o simplemente incorrectas.

@manuelm Quería ser amable y dije "nosotros". Obviamente, LD_LIBRARY_PATH solucionaría los problemas de no encontrar bibliotecas en el directorio de compilación (a menos que se restablezca en algún lugar, que parece ser el caso al menos para las pruebas de Python / lua GI). Pero si su teoría es correcta de que RPATH debe establecerse en el binario, también se romperá la versión instalada, lo que actualmente no está realmente confirmado. Esto debería investigarse.

Mi teoría ya no es solo una teoría, porque he hecho la prueba.

Una vez más: en Linux los enlaces funcionan porque la biblioteca que implementa los enlaces ( kdb.so para lua / python y libgelektra-4.0.so para glib) tiene DT_RPATH set _AND_ dlopen honra esto.

Por supuesto, los enlaces funcionarán después de que elektra se haya instalado en las rutas de la biblioteca del sistema global. No veo absolutamente ninguna razón por la que esto deba dejar de funcionar de repente.

Las pruebas de los enlaces no funcionan para! = Linux. Eso es todo.

PD: Sé que las pruebas de enlaces GI requieren LD_LIBRARY_PATH. Es por eso que quería que agregaras algún tipo de macro de sistema de compilación que integre / anexe el caso GI.

Parece que las pruebas de enlace son el único lugar donde se necesita LD_LIBRARY_PATH, así que lo agregué allí.

@mpranj ¿ Ojalá tengamos pronto un travis que pueda confirmar si funciona?

@ markus2330 no, no funciona. (ni en travis ni en mi máquina)

@mpranj gracias por probar. ¿Tiene el archivo travis listo para volver a probarlo sin molestar a nadie? ¿Ambos casos de prueba siguen fallando? ¿Olvidé LD_LIBRARY_PATH en alguna parte o el enfoque simplemente no funciona?

@ markus2330 sí, actualmente estoy probando en travis, pero tiene casi el mismo comportamiento que en mi máquina. Parece que da243f9e25d8fa14f8286c48b4338a73c1e7242d no hizo ninguna diferencia.

Puedes verlo aquí: https://travis-ci.org/mpranj/libelektra
Y por cierto, parece que @manuelm prácticamente se hizo con travis + OS X. Las pruebas fallan, pero en realidad Travis está casi configurado por completo, supongo.

Sí, dijo eso. Principalmente faltaba la configuración de la matriz para construir Mac OS X y otros con un archivo travis.

Gracias por toda su ayuda, el problema debería solucionarse ahora.