Libelektra: Certains tests échouent sur OS X

Je suis désolé mais je n'ai pas OS X. Cependant, ctest -V est votre ami.

d'ailleurs, appeler lua $file n'est pas la même chose que d'exécuter les tests. Vous utilisez la bibliothèque kdb installée sur le système tandis que les tests utilisent évidemment la bibliothèque située dans le répertoire de construction. Vous devez au moins définir LUA_CPATH . voir https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/swig/lua/tests/CMakeLists.txt#L12

90% des plantages liés aux swig étaient liés à des défauts de l'environnement de construction. Essayez donc d'abord de régénérer (!) + de recompiler les liaisons de swig.

Ce problème peut être lié à ad537b3 (au moins sur Linux, kdb*lua|python plantait, mais le correctif pour Linux fait partie de ad537b3). Sans sortie du test, on ne peut pas vraiment dire.

Vous pouvez utiliser make run_all qui supprime la sortie des cas de test réussis mais affiche la sortie de ceux qui ont échoué.

@sanssecours Une mise à jour à ce sujet ?

Ce problème peut être lié à ad537b3 (au moins sur Linux, kdb*lua|python plantait, mais le correctif pour Linux fait partie de ad537b3). Sans sortie du test, on ne peut pas vraiment dire.

@sanssecours Une mise à jour à ce sujet ?

Désolé pour la réponse tardive. Je pensais avoir déjà écrit un commentaire contenant des informations détaillées sur ce problème. Permettez-moi de commencer par dire que testpy2_kdb.py échoue également sur ma machine. Cela pourrait donc être un problème avec ma configuration spécifique. J'ai installé SWIG via Homebrew et j'utilise actuellement la commande cmake pour générer les fichiers de construction pour Elektra :

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

Voici le résultat 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

On dirait que Lua ne parvient pas à trouver libelektra-resolver.so , qui se trouve dans build/lib et /usr/local/lib/elektra sur ma machine. Dois-je définir un chemin de bibliothèque pour que cela fonctionne ? Soit dit en passant, il semble que testpy2_kdb.py échoue également à cause du même problème.

Les liaisons ne chargent aucune bibliothèque elektra lors de l'exécution. Ce ne sont que des liaisons. Vous pouvez le voir en regardant l'emplacement exact de l'erreur, qui est ../src/libs/loader/dl.c:82 .

Il s'agit donc soit d'un problème avec votre environnement, soit d'un problème électrique général sur OSX, soit d'un problème de système de build sur OSX. Je soupçonne le premier. ping @markus2330

dlopen(libelektra-resolver.so, 2): image not found semble en fait que cela n'a rien à voir avec lua.

libelektra-resolver.so devrait être un lien symbolique vers le résolveur que vous avez sélectionné avec KDB_DEFAULT_RESOLVER , peut-être que votre configuration/installation est cassée ? Pouvez-vous vérifier si les liens symboliques sont corrects ?

C'est étrange : libelektra-resolver.so est utilisé dans tous les cas de test liés à kdb, pourquoi cela ne fonctionne-t-il _pas_ uniquement dans ce cas de test ? Peut-être que ce cas de test (et celui de python) utilise la bibliothèque installée et non la bibliothèque du répertoire de construction. Pouvez-vous vérifier avec strace quels libelektra-resolver.so le scénario de test essaie de charger ?

image not found est assez générique, il se peut que dans la bibliothèque l'image de votre architecture ne soit pas trouvée ? Utilisez-vous des binaires gras ?

libelektra-resolver.so devrait être un lien symbolique vers le résolveur que vous avez sélectionné avec KDB_DEFAULT_RESOLVER , peut-être que votre configuration/installation est cassée ?

Existe-t-il un moyen simple de vérifier si l'installation locale d'Elektra est défectueuse ? La commande kdb semble fonctionner.

Pouvez-vous vérifier si les liens symboliques sont corrects ?

Les deux alias libelektra-resolver.so renvoient à un fichier libelektra-resolver_fm_hpu_b.so situé dans le même répertoire que les alias. Il semble donc qu'ils aient raison.

Pouvez-vous vérifier avec strace quels libelektra-resolver.so le scénario de test essaie de charger ?

J'ai essayé sudo dtruss ctest -V -R test_kdb.lua . Voici la sortie :
test_kdb.lua - dtruss Output.txt . On dirait que le test utilise la version Elektra dans le répertoire de construction. J'ai désinstallé Elektra via sudo ninja uninstall . J'ai ensuite refait le test. Le rendu est toujours le même.

Utilisez-vous des binaires gras ?

Pas à ma connaissance.

Utilisez-vous OSX El Capitan ? Il peut s'agir d'un problème étrange de

C'est assez étrange que kdb fonctionne cependant.

S'il s'agit d'une protection de l'intégrité du système en raison de l'installation de python/lua, cela peut avoir du sens.

Utilisez-vous OSX El Capitan ? Il peut s'agir d'un problème étrange de protection de l'intégrité du système.

Oui, j'utilise OS X 10.11.4. J'ai temporairement désactivé SIP et j'ai réexécuté le test. Toujours le même problème. Bien qu'après avoir désactivé SIP, j'ai rencontré un nouveau test qui échoue : testscr_check_kdb_internal_suite . Et maintenant testscr_check_merge ne fonctionne plus non plus 😢.

Je suis revenu à la version 0.8.16, j'ai nettoyé mon répertoire de construction et j'ai réexécuté ninja test . testscr_check_kdb_internal_suite et testscr_check_merge échouent toujours, même si je me souviens qu'au moins testscr_check_kdb_internal_suite fonctionnait quand Elektra 0.8.16 est sorti. Voici le résultat du test supplémentaire qui échoue maintenant également :
testscr_check_kdb_internal_suite.txt
testscr_check_merge.txt

J'ai changé le titre et me suis retiré. Je n'ai pas d'accès direct à une machine OSX et manque de connaissances approfondies. Sans une machine pour fouiller, je ne peux rien dire de la sortie du texte.

Avez-vous également regardé les autres astuces des liens? Par exemple, réinstaller python/lua ?

@petermax2 @mpranj Pouvez-vous reproduire ces problèmes ?

Avez-vous également regardé les autres astuces des liens? Par exemple, réinstaller python/lua ?

Désolé, pas vraiment. L'installation Python 2 est celle fournie avec le système. Pour le réinstaller, je devrais réinstaller tout le système d'exploitation.

Je n'ai installé Lua que pour tester le plugin Lua Elektra. Je ne pense donc pas que la réinstallation ait beaucoup de sens. Cependant, comme cela ne prend que quelques secondes, j'ai exécuté brew reinstall lua . Après cela, j'ai commencé avec un répertoire de construction propre, j'ai exécuté les commandes de construction et ctest -VV -R test_kdb.lua . Le test montre toujours la même sortie.

Au fait : Les tests testscr_check_kdb_internal_suite et testscr_check_merge fonctionnent à nouveau correctement, après avoir supprimé tous les fichiers de /etc/kdb .

Je n'ai actuellement pas d'autre idée. (sauf isolement fastidieux du problème : pour réduire l'appel dlopen à un exemple minimal où cela ne fonctionnera pas) Il serait donc préférable d'attendre si quelqu'un peut reproduire le problème, peut-être que cela jettera un nouvel éclairage sur le problème.

Je peux confirmer le même comportement sur ma machine.

Solution : définissez correctement le chemin de la bibliothèque : par exemple
LD_LIBRARY_PATH="/Users/mpranj/workspace/libelektra/build/lib" ctest -V -R test_kdb.lua fonctionne très bien pour moi.

dlopen sur OS X recherche $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH , je pense dans cet ordre.

Le PR #710 le corrige, mais je ne sais pas si le correctif est très propre.

Non, le correctif n'est certainement pas propre.

Autant que je me souvienne, nos tests reposent sur le fait que DT_RPATH est défini dans libelektra-kdb.so . Si cela n'est pas disponible sur OSX, nous devons le définir dans un environnement de construction global.

Edit : Mais merci de l'avoir découvert !

RPATH est défini pour toutes les bibliothèques principales, mais peut-être que libelektra-core devrait suffire : à cet endroit, le dlopen se produit.

Est-ce que image not found signifie simplement bibliothèque introuvable ? Si oui, avez-vous une idée de la raison pour laquelle le RPATH fonctionne pour tous les tests sauf lua et python ?

Juste pour votre information : Elektra prend également en charge les systèmes sans RPATH (par exemple, openwrt avec musl comme libc) en définissant simplement TARGET_PLUGIN_FOLDER sur une chaîne vide.

Il semble que des choses similaires se produisent sur FreeBSD d'ailleurs.

 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:

Je n'ai pas encore pu vérifier lua sur FreeBSD.

@mpranj bon à savoir, donc FreeBSD semble être un bon indice s'il fonctionne aussi avec MacOSX (à côté d'OpenBSD). Les autres tests kdb et l'outil de ligne kdb commande

Pouvez-vous ouvrir des problèmes ou ajouter des problèmes OpenBSD sur les cas de test qui ne fonctionnent pas sur FreeBSD ?

Si vous voulez dire ceux-ci :

        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

... alors oui. L'outil kdb semble fonctionner (juste une vérification rapide avec ls).

Sinon, beaucoup de choses échouent mais je ne pourrai pas tout vérifier/rapporter aujourd'hui. Mais bien sûr, je rapporterai tout quand je pourrai le tester correctement.

Je suppose que les tests kdb fonctionnent parce qu'ils sont liés de manière statique, n'est-ce pas ?
Si je désactive BUILD_STATIC les tests ne fonctionnent pas non plus.

@markus2330 Je ne pense pas que nous puissions éviter de définir LD_LIBRARY_PATH sur certaines plates-formes. Comment fonctionne TARGET_PLUGIN_FOLDER ? Ou plus précisément, comment cela résout-il la recherche dynamique dans les bibliothèques ?

Merci c'est une bonne idée : @sanssecours peux-tu désactiver BUILD_STATIC et BUILD_FULL et relancer tous les tests ( testkdb ) ?

Si TARGET_PLUGIN_FOLDER est vide, les plugins sont installés là où se trouvent les bibliothèques et aucun RPATH ou LD_LIBRARY_PATH n'est nécessaire. Mais cela n'aiderait que lorsque l'Elektra installé est utilisé (ce qui pourrait être le cas pour les tests python / lua ).

https://cmake.org/Wiki/CMake_RPATH_handling dit ".. RPATH sur Mac OS X. Il sera activé à la fois pour l'arborescence de construction et l'arborescence d'installation", donc en fait, les binaires de l'arborescence de construction devraient également avoir RPATH défini. @sanssecours Pouvez-vous vérifier cela ? Par exemple, en utilisant readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

Le problème ne concerne pas RPATH lui-même, mais environ dlopen sur Linux lisant DT_RPATH par rapport aux autres plates-formes.

man dlopen de la glibc :

• (ELF uniquement) Si le fichier exécutable du programme appelant contient une balise DT_RPATH et ne contient pas de balise DT_RUNPATH, les répertoires répertoriés dans la balise DT_RPATH sont recherchés.
• Si, au moment où le programme a été lancé, la variable d'environnement LD_LIBRARY_PATH a été définie pour contenir une liste de répertoires séparés par des deux-points, alors ceux-ci sont recherchés. (Par mesure de sécurité, cette variable est ignorée pour les programmes set-user-ID et set-group-ID.)
• (ELF uniquement) Si le fichier exécutable du programme appelant contient une balise DT_RUNPATH, les répertoires répertoriés dans cette balise sont recherchés.
• Le fichier cache /etc/ld.so.cache (maintenu par ldconfig(8)) est vérifié pour voir s'il contient une entrée pour le nom de fichier.
• Les répertoires /lib et /usr/lib sont recherchés (dans cet ordre).

man dlopen sur OSX :

Lorsque le chemin ne contient pas de barre oblique (c'est-à-dire qu'il s'agit simplement d'un nom de feuille), dlopen() recherche les éléments suivants jusqu'à ce qu'il trouve un fichier Mach-O compatible : $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, répertoire de travail actuel, $DYLD_FALLBACK_LIBRARY_PATH.

dlopen devrait fonctionner avec des chemins absolus ici, ou il doit être dans l'un des chemins mentionnés ci-dessus

Mais nous ne faisons pas de chemins absolus. Donc aucune idée de l'utilité de ces informations

RPATH absolu ou chemins absolus vers les plugins ? CMake prétend qu'il prend en charge le RPATH de l'arbre de construction, il doit donc utiliser un RPATH absolu si nécessaire.

Les chemins absolus vers les plugins sont ce que beaucoup font et ce serait un changement facile, mais je ne vois pas en quoi cela n'aiderait pas pour les cas de test intégrés.

Tout d'abord, il serait intéressant de savoir quel est le problème réel ici. La version installée fonctionne-t-elle vraiment à fond ? Par exemple, kdb run_all serait également intéressant (à côté de ce que j'ai déjà écrit ci-dessus).

Ma pâte des pages de manuel dlopen indique clairement de quoi il s'agit.
Le chemin de recherche de dlopen(libelektra-resolver.so) est différent sur différentes plates-formes. Linux fonctionne car dlopen honore DT_RPATH de libelektra-kdb.so

Il semble que le réglage de LD_LIBRARY_PATH soit également ce que fait la valve.
https://github.com/ValveSoftware/steam-runtime/blob/master/runtime/run.sh

Vous voulez dire que le problème est qu'ils n'écrivent pas de documentation ? @rpath n'y est même pas mentionné.

Je pense que tant que nous ne savons pas ce qui fonctionne réellement une fois installé/avec BUILD_SHARED, nous ne devrions pas spéculer davantage.

@markus2330
EDIT : désactivation de BUILD_STATIC et BUILD_FULL :
les tests testkdb* fonctionnent correctement.

À propos de la documentation, ils mentionnent @rpath ici .

Je viens de vérifier ma déclaration par un court exemple :

• runtimelib ...une bibliothèque fournissant des fonctions aléatoires. (comme elektra-resolver)
• lib ...une bibliothèque qui charge runtimelib à l'exécution en utilisant dlopen . Il a DT_RPATH défini sur le répertoire de runtimelib . (comme kdb.so des liaisons)
• runner ...un exécutable qui charge lib à l'exécution en utilisant dlopen (comme lua/python)

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

Ce scénario fonctionne sous Linux, mais échoue sous FreeBSD.

Je sais que RPATH défini dans une bibliothèque n'est pas portable (cela ne fonctionnait pas non plus pour musl). Mais cela semblait fonctionner pour Mac OS X ( @mpranj a également signalé que les tests testkdb* fonctionnaient bien et @omnidan a signalé que kdb fonctionnait avec Mac OS X). J'ai donc demandé à enquêter sur les raisons pour lesquelles seuls les tests python/lua échouent.

Le moyen portable d'installer Elektra ne définit pas TARGET_PLUGIN_FOLDER et pour les tests, nous pourrions utiliser (comme suggéré) LD_LIBRARY_PATH . (Nous aurions seulement besoin de le définir dans run_memcheck et run_all).

@mpranj a également signalé que les tests testkdb* fonctionnaient bien et @omnidan a signalé que kdb fonctionnait avec Mac OS X

testkdb* et kdb ont DT_RPATH définis eux-mêmes. Python et l'interpréteur lua ne l'ont pas fait. C'est fondamentalement différent.

[...] et pour les tests, nous pourrions utiliser (comme suggéré) LD_LIBRARY_PATH.

Alors s'il vous plaît ajoutez-le. Merci

Oui, vous avez raison pour le système de construction : CMake semble définir RPATH sur chaque exécutable, mais évidemment pas pour python/lua.

Une fois installé, cependant, il ne serait pas défini. Alors s'il vous plaît, quelqu'un confirme si kdb fonctionne (avec TARGET_PLUGIN_FOLDER défini).

@sanssecours pouvez-vous désactiver BUILD_STATIC et BUILD_FULL et relancer tous les tests ( testkdb ) ?

On dirait que cela ne change pas grand-chose, sauf que ninja test exécute moins de tests (54 au lieu de 114). Les tests test_kdb.lua et testpy2_kdb.py échouent toujours. Tous les autres tests (semblent) fonctionner.

https://cmake.org/Wiki/CMake_RPATH_handling dit ".. RPATH sur Mac OS X. Il sera activé à la fois pour l'arborescence de construction et l'arborescence d'installation", donc en fait, les binaires de l'arborescence de construction devraient également avoir RPATH défini. Par exemple, en utilisant readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

J'ai utilisé la commande otool -l lib/libelektra-resolver.so — libelektra-core.so.0.8.16 n'existe pas sur ma machine. Selon la sortie :

…
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 défini.

Par exemple, kdb run_all serait également intéressant (à côté de ce que j'ai déjà écrit ci-dessus).

Sur ma machine, 5 tests sur 655 échouent. 4 des tests ( testmod_crypto , testmod_iterate , testmod_semlock et testmod_template ) échouent à cause de la même erreur de base :

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

Le test testmod_python2 affiche la sortie d'erreur suivante :

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

Vous trouverez ci-dessous la sortie de testmod_lua , qui ne signale aucune erreur.

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

Sur OS X, des dylibs sont créés, pas .so. Il existe certainement un libelektra-core.0.8.16.dylib ou similaire.

Il existe certainement un libelektra-core.0.8.16.dylib ou similaire.

Vous avez raison. On dirait que RPATH n'est pas défini pour libelektra-core.0.8.16.dylib , car otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH n'affiche aucune sortie.

Ne pas grep la sortie est courte, ou grep en minuscules rpath

Ne pas grep la sortie est courte, ou grep en minuscules rpath

Voulez-vous dire « Ne pas grep sortie, c'est court, ou grep minuscule rpath » ? Si oui, pourquoi pas ? J'ai également recherché RPATH dans la sortie de otool -l lib/libelektra-core.0.8.16.dylib via la recherche intégrée de mon application Terminal. Cela ne montre également aucune occurrence de LC_RPATH .

Si je recherche rpath , alors je vois une occurrence 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
...

Pour autant que je sache, @rpath n'est qu'un espace réservé pour (les valeurs stockées dans) RPATH . Je ne pense pas que cette occurrence de rpath nous indique si RPATH est défini ou non.

Selon le wiki CMake, la commande otool -l <file> | grep LC_RPATH -A2 est un moyen possible d'afficher les RPATH de certains fichiers. Je pense que la version moins sophistiquée que j'ai utilisée – otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH – devrait être plus ou moins bien aussi.

Les gars, pourquoi vérifiez-vous cela?

@sanssecours désolé, j'ai envoyé le message rapidement depuis mon téléphone, donc je n'ai pas vu que ça n'avait aucun sens.

Je faisais référence à otool -L qui montre les dépendances et n'affiche que @rpath . Mais oui, vous avez raison otool -l est la bonne commande.

Au fait, je n'ai trouvé aucune bibliothèque dans mon système qui utilise RPATH, à l'exception d'elektra.

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

Comme @manuelm l' indique cependant, ces vérifications pourraient être plutôt inutiles ...

Je ne pense pas que nous comprenions parfaitement tous les problèmes ci-dessus, mais je conviens que le type de débogage à distance que nous effectuons n'est pas efficace. Quelqu'un devrait enquêter et documenter quelle est la meilleure façon de prendre en charge les systèmes non glibc. Discutons lors de la réunion de la manière de procéder.

@ markus2330 Je comprends parfaitement le problème. Définissez LD_LIBRARY_PATH avant le début des tests et je vous promets que le problème est résolu.

Tous les autres problèmes mentionnés sont des faux-fuyants ou tout simplement faux.

@manuelm je voulais être gentil et j'ai dit "nous". De toute évidence, le LD_LIBRARY_PATH résoudrait les problèmes de ne pas trouver de bibliothèques dans le répertoire de construction (à moins qu'il ne soit réinitialisé quelque part, ce qui semble être le cas au moins pour les tests python/lua GI). Mais si votre théorie est correcte selon laquelle RPATH doit être défini dans le binaire, la version installée serait également cassée, ce qui n'est actuellement pas vraiment confirmé. Cela devrait faire l'objet d'une enquête.

Ma théorie n'est plus seulement une théorie, parce que j'ai fait la preuve.

Encore une fois : sur Linux, les liaisons fonctionnent car la bibliothèque implémentant les liaisons ( kdb.so pour lua/python et libgelektra-4.0.so pour glib) a DT_RPATH défini _AND_ dlopen honore cela.

Bien sûr, les liaisons fonctionneront après l'installation d'elektra dans les chemins de la bibliothèque système globale. Je ne vois absolument aucune raison pour que cela cesse soudainement de fonctionner.

Les tests des bindings ne fonctionnent pas pour !=linux. C'est tout.

PS : je sais que les tests de liaisons GI nécessitent LD_LIBRARY_PATH. C'est pourquoi je voulais que vous ajoutiez une sorte de macro de système de construction qui intègre/ajoute le boîtier GI.

Il semble que les tests de liaison soient le seul endroit où le LD_LIBRARY_PATH est nécessaire, alors je l'ai ajouté juste là.

@mpranj J'espère que nous aurons bientôt un travis qui pourra confirmer si cela fonctionne ?

@markus2330 non, cela ne fonctionne pas. (ni sur travis ni sur ma machine)

@mpranj merci pour les tests. Avez-vous le fichier travis prêt à le tester à nouveau sans déranger personne ? Les deux cas de test échouent toujours? Ai-je oublié LD_LIBRARY_PATH quelque part ou l'approche ne fonctionne-t-elle tout simplement pas ?

@markus2330 oui, je teste actuellement sur travis, mais il a principalement le même comportement que sur ma machine. Il semble que da243f9e25d8fa14f8286c48b4338a73c1e7242d n'ait fait aucune différence.

Vous pouvez le voir ici : https://travis-ci.org/mpranj/libelektra
Et d'ailleurs, il semble que @manuelm ait été à peu près terminé avec travis + OS X. Les tests échouent, mais travis est en fait presque complètement configuré, je suppose.

Oui, il a dit ça. La configuration matricielle pour construire Mac OS X et d'autres avec un seul fichier Travis manquait principalement.

Merci pour votre aide, le problème devrait être résolu maintenant.