Libelektra: Einige Tests schlagen unter OS X fehl

Es tut mir leid, aber ich habe kein OS X. ctest -V ist jedoch dein Freund.

Übrigens ist das Aufrufen von lua $file nicht dasselbe wie das Ausführen der Tests. Sie verwenden die vom System installierte kdb-Bibliothek, während die Tests offensichtlich die Bibliothek verwenden, die sich im Build-Verzeichnis befindet. Sie sollten mindestens LUA_CPATH festlegen. siehe https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/swig/lua/tests/CMakeLists.txt#L12

90% der swig-bezogenen Abstürze waren auf Fehler in der Build-Umgebung zurückzuführen. Versuchen Sie also zuerst, die Swig-Bindungen zu regenerieren (!) + neu zu kompilieren.

Dieses Problem könnte mit ad537b3 zusammenhängen (zumindest unter Linux stürzte kdb*lua|python ab, aber die Fehlerbehebung für Linux ist Teil von ad537b3). Ohne Ausgabe des Tests kann man nicht wirklich sagen.

Sie können make run_all , um die Ausgabe erfolgreicher Testfälle zu unterdrücken, aber die Ausgabe für die fehlgeschlagenen anzuzeigen.

@sanssecours Gibt es dazu ein Update?

Dieses Problem könnte mit ad537b3 zusammenhängen (zumindest unter Linux stürzte kdb*lua|python ab, aber die Fehlerbehebung für Linux ist Teil von ad537b3). Ohne Ausgabe des Tests kann man nicht wirklich sagen.

@sanssecours Gibt es dazu ein Update?

Entschuldigung für die späte Antwort. Ich dachte, ich hätte bereits einen Kommentar geschrieben, der erweiterte Informationen zu diesem Thema enthält. Lassen Sie mich damit beginnen, dass testpy2_kdb.py auch auf meinem Computer fehlschlägt. Es könnte also ein Problem mit meinem spezifischen Setup sein. Ich habe SWIG über Homebrew installiert und verwende derzeit den folgenden cmake Befehl, um die Build-Dateien für Elektra zu generieren:

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

Hier ist die Ausgabe von 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

Anscheinend kann Lua libelektra-resolver.so , das sich in build/lib und /usr/local/lib/elektra auf meinem Computer befindet. Muss ich einen Bibliothekspfad festlegen, damit dies funktioniert? Übrigens, es sieht so aus, als ob testpy2_kdb.py auch wegen genau dem gleichen Problem fehlschlägt.

Die Bindings laden keine Elektra-Bibliothek zur Laufzeit. Sie sind nur Bindungen. Sie können dies sehen, indem Sie sich den genauen Fehlerort ansehen, der ../src/libs/loader/dl.c:82 .

Dies ist also entweder ein Problem mit Ihrer Umgebung, ein allgemeines Elektra-Problem unter OSX oder ein Build-System-Problem unter OSX. Ich vermute ersteres. ping @markus2330

dlopen(libelektra-resolver.so, 2): image not found sieht tatsächlich so aus, als hätte es nichts mit lua zu tun.

libelektra-resolver.so sollte ein Symlink zu dem Resolver sein, den Sie mit KDB_DEFAULT_RESOLVER , vielleicht ist Ihr Setup/Ihre Installation defekt? Können Sie überprüfen, ob die Symlinks korrekt sind?

Seltsam ist: libelektra-resolver.so wird in jedem kdb-bezogenen Testfall verwendet, warum funktioniert es nur in diesem Testfall _nicht_? Vielleicht verwendet dieser Testfall (und der Python) die installierte Bibliothek und nicht die Bibliothek im Build-Verzeichnis. Können Sie mit strace überprüfen, welche libelektra-resolver.so der Testfall zu laden versucht?

image not found ist ziemlich generisch, kann es sein, dass in der Bibliothek das Image für Ihre Architektur nicht gefunden wird? Verwenden Sie fette Binärdateien ?

libelektra-resolver.so sollte ein Symlink zu dem Resolver sein, den Sie mit KDB_DEFAULT_RESOLVER , vielleicht ist Ihr Setup/Ihre Installation defekt?

Gibt es eine einfache Möglichkeit zu überprüfen, ob die lokale Elektra-Installation defekt ist? Der Befehl kdb scheint zu funktionieren.

Können Sie überprüfen, ob die Symlinks korrekt sind?

Beide libelektra-resolver.so Aliasnamen verweisen auf eine Datei libelektra-resolver_fm_hpu_b.so sich im selben Verzeichnis wie die Aliase befindet. Sie scheinen also richtig zu sein.

Können Sie mit strace überprüfen, welche libelektra-resolver.so der Testfall zu laden versucht?

Ich habe sudo dtruss ctest -V -R test_kdb.lua versucht. Hier ist die Ausgabe:
test_kdb.lua -dtruss Ausgabe.txt . Sieht so aus, als würde der Test die Elektra-Version im Build-Verzeichnis verwenden. Ich habe Elektra über sudo ninja uninstall deinstalliert. Ich habe den Test dann nochmal durchgeführt. Die Ausgabe ist immer noch die gleiche.

Verwenden Sie fette Binärdateien?

Nicht dass ich wüsste.

Benutzt du OSX El Capitan? Es könnte sich um ein seltsames Problem mit dem Systemintegritätsschutz handeln .

Es ist irgendwie seltsam, dass kdb funktioniert.

Wenn es wegen der Python/lua-Installation mit einem Systemintegritätsschutz zu tun hat, kann es sinnvoll sein.

Benutzt du OSX El Capitan? Es könnte sich um ein seltsames Problem mit dem Systemintegritätsschutz handeln.

Ja, ich verwende OS X 10.11.4. Ich habe SIP vorübergehend deaktiviert und den Test erneut durchgeführt. Immer noch das gleiche Problem. Obwohl ich nach dem Deaktivieren von SIP auf einen neuen Test gestoßen bin, der fehlschlägt: testscr_check_kdb_internal_suite . Und jetzt geht testscr_check_merge auch nicht mehr 😢.

Ich ging zurück zu 0.8.16, bereinigte mein Build-Verzeichnis und ließ ninja test erneut laufen. Sowohl testscr_check_kdb_internal_suite als auch testscr_check_merge scheitern immer noch, obwohl ich mich daran erinnert habe, dass mindestens testscr_check_kdb_internal_suite funktioniert hat, als Elektra 0.8.16 veröffentlicht wurde. Hier ist die Ausgabe des zusätzlichen Tests, der jetzt ebenfalls fehlschlägt:
testcr_check_kdb_internal_suite.txt
testcr_check_merge.txt

Ich habe den Titel geändert und mich selbst entfernt. Ich habe keinen direkten Zugriff auf einen OSX-Rechner und es fehlen mir fundierte Kenntnisse. Ohne eine Maschine zum Herumstöbern kann ich der Textausgabe nichts entnehmen.

Hast du dir auch die anderen Hinweise der Links angeschaut? ZB Python/lua neu installieren?

@petermax2 @mpranj Können Sie diese Probleme reproduzieren?

Hast du dir auch die anderen Hinweise der Links angeschaut? ZB Python/lua neu installieren?

Entschuldigung, nicht wirklich. Die Installation von Python 2 ist diejenige, die mit dem System geliefert wurde. Um es neu zu installieren, müsste ich das gesamte Betriebssystem neu installieren.

Ich habe Lua nur installiert, um das Lua Elektra-Plugin zu testen. Daher halte ich eine Neuinstallation nicht für sinnvoll. Da es jedoch nur Sekunden dauert, habe ich brew reinstall lua . Danach habe ich mit einem sauberen Build-Verzeichnis angefangen, die Build-Befehle ausgeführt und ctest -VV -R test_kdb.lua . Der Test zeigt immer noch die gleiche Ausgabe.

Übrigens: Die Tests testscr_check_kdb_internal_suite und testscr_check_merge funktionieren nun auch wieder korrekt, nachdem ich alle Dateien aus /etc/kdb .

Eine andere Idee habe ich aktuell nicht. (außer zeitraubende Isolierung des Problems: um den dlopen-Aufruf auf ein minimales Beispiel zu reduzieren, wo es nicht funktioniert) Also am besten warten, wenn jemand das Problem reproduzieren kann, vielleicht wirft es neues Licht auf das Problem.

Ich kann das gleiche Verhalten auf meinem Rechner bestätigen.

Lösung: Stellen Sie den Bibliothekspfad richtig ein: zB
LD_LIBRARY_PATH="/Users/mpranj/workspace/libelektra/build/lib" ctest -V -R test_kdb.lua funktioniert bei mir einwandfrei.

dlopen unter OS X sucht $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH , ich denke in dieser Reihenfolge.

Der PR #710 behebt es, ich bin mir jedoch nicht sicher, ob das Update sehr sauber ist.

Nein, der Fix ist definitiv nicht sauber.

Soweit ich mich erinnere, basieren unsere Tests darauf, dass DT_RPATH in libelektra-kdb.so . Wenn dies unter OSX nicht verfügbar ist, sollten wir dies in einer globalen Build-Umgebung definieren.

Edit: Aber danke, dass du es herausgefunden hast!

RPATH ist für alle Kernbibliotheken gesetzt, aber vielleicht sollte libelektra-core ausreichen: an dieser Stelle passiert das dlopen .

Bedeutet image not found einfach, dass die Bibliothek nicht gefunden wurde? Wenn ja, haben Sie eine Idee, warum RPATH für alle Tests außer den Lua- und Python-Tests funktioniert?

Nur zur Information: Elektra unterstützt auch Systeme ohne RPATH (zB openwrt mit musl als libc), indem einfach TARGET_PLUGIN_FOLDER auf einen leeren String gesetzt wird.

Es scheint, dass ähnliche Dinge auf FreeBSD passieren.

 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:

Konnte Lua auf FreeBSD noch nicht überprüfen.

@mpranj gut zu wissen, also scheint FreeBSD ein guter Hinweis zu sein, wenn es auch mit MacOSX (neben OpenBSD) funktioniert. Funktionieren die anderen kdb Testfälle und das kdb Befehlszeilentool?

Können Sie Ausgaben zu Testfällen öffnen oder an OpenBSD-Ausgaben anhängen, die unter FreeBSD nicht funktionieren?

Wenn du diese meinst:

        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

... dann ja. Das Tool kdb scheint zu funktionieren (nur eine kurze Überprüfung mit ls).

Ansonsten scheitern viele Dinge, aber ich kann heute nicht alles überprüfen/melden. Aber sicher werde ich alles berichten, wenn ich es richtig testen kann.

Meine Vermutung ist, dass die kdb-Tests funktionieren, weil sie statisch verknüpft sind, oder?
Wenn ich BUILD_STATIC deaktiviere, funktionieren die Tests auch nicht.

@markus2330 Ich glaube nicht, dass wir es vermeiden können, auf einigen Plattformen LD_LIBRARY_PATH festzulegen . Wie funktioniert TARGET_PLUGIN_FOLDER ? Oder genauer, wie löst dies die dynamische Bibliothekssuche?

Danke, das ist eine gute Idee: @sanssecours können Sie BUILD_STATIC und BUILD_FULL deaktivieren und alle ( testkdb ) Tests erneut ausführen?

Wenn TARGET_PLUGIN_FOLDER leer ist, werden die Plugins dort installiert, wo die Bibliotheken sind und es wird kein RPATH oder LD_LIBRARY_PATH benötigt. Aber es würde nur helfen, wenn die installierte Elektra verwendet wird (was bei den python / lua Tests der Fall sein könnte).

https://cmake.org/Wiki/CMake_RPATH_handling sagt ".. RPATH on Mac OS X. Es wird sowohl für den Build-Tree als auch für den Installations-Tree aktiviert", also sollten eigentlich auch die Build-Tree-Binärdateien RPATH gesetzt haben. @sanssecours Können Sie das überprüfen? ZB mit readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

Das Problem betrifft nicht RPATH selbst, sondern dlopen unter Linux beim Lesen von DT_RPATH im Vergleich zu anderen Plattformen.

man dlopen von glibc:

• (nur ELF) Wenn die ausführbare Datei für das aufrufende Programm ein DT_RPATH-Tag und kein DT_RUNPATH-Tag enthält, werden die im DT_RPATH-Tag aufgelisteten Verzeichnisse durchsucht.
• Wenn zum Zeitpunkt des Programmstarts die Umgebungsvariable LD_LIBRARY_PATH so definiert war, dass sie eine durch Doppelpunkte getrennte Liste von Verzeichnissen enthält, werden diese durchsucht. (Aus Sicherheitsgründen wird diese Variable für set-user-ID- und set-group-ID-Programme ignoriert.)
• (nur ELF) Wenn die ausführbare Datei für das aufrufende Programm ein DT_RUNPATH-Tag enthält, werden die darin aufgeführten Verzeichnisse durchsucht.
• Die Cache-Datei /etc/ld.so.cache (verwaltet von ldconfig(8)) wird daraufhin überprüft, ob sie einen Eintrag für den Dateinamen enthält.
• Die Verzeichnisse /lib und /usr/lib werden durchsucht (in dieser Reihenfolge).

man dlopen unter OSX:

Wenn path keinen Schrägstrich enthält (dh es ist nur ein Blattname), durchsucht dlopen() Folgendes, bis es eine kompatible Mach-O-Datei findet: $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, aktuelles Arbeitsverzeichnis, $DYLD_FALLBACK_LIBRARY_PATH.

dlopen sollte hier mit absoluten Pfaden funktionieren, oder es muss sich in einem der oben genannten Pfade befinden

Aber wir machen keine absoluten Pfade. Also keine Ahnung, wie diese Informationen helfen

Absoluter RPATH oder absolute Pfade zu Plugins? CMake behauptet, dass es Unterstützung für Build-Tree-RPATH hat, daher sollte es bei Bedarf einen absoluten RPATH verwenden.

Absolute Pfade zu Plugins sind das, was viele tun, und es wäre eine einfache Änderung, aber ich sehe nicht, wie es für die eingebauten Testfälle nicht helfen würde.

Zunächst wäre es interessant, was hier das eigentliche Problem ist. Funktioniert die installierte Version wirklich vollständig? ZB kdb run_all wäre auch interessant (neben dem, was ich oben schon geschrieben habe).

Meine Paste von dlopen manpages gibt deutlich an, worum es bei dem Problem geht.
Der Suchpfad von dlopen(libelektra-resolver.so) ist auf verschiedenen Plattformen unterschiedlich. Linux funktioniert, weil dlopen DT_RPATH der libelektra-kdb.so berücksichtigt

Es scheint, dass die Einstellung von LD_LIBRARY_PATH ist, was Valve auch tut.
https://github.com/ValveSoftware/steam-runtime/blob/master/runtime/run.sh

Sie meinen, das Problem ist, dass sie keine Dokumentation schreiben? @rpath wird dort nicht einmal erwähnt.

Ich denke, bis wir nicht wissen, was bei der Installation/mit BUILD_SHARED tatsächlich funktioniert, sollten wir nicht weiter spekulieren.

@markus2330
BEARBEITEN: Deaktivieren von BUILD_STATIC und BUILD_FULL:
die testkdb*-Tests laufen einwandfrei.

Über Dokumentation, sie erwähnen @rpath hier .

Habe meine Aussage gerade durch ein kurzes Beispiel bestätigt:

• runtimelib ...eine Bibliothek mit einigen zufälligen Funktionen. (wie Elektro-Resolver)
• lib ...eine Bibliothek, die runtimelib zur Laufzeit mit dlopen lädt. Es hat DT_RPATH auf das Verzeichnis von runtimelib . (wie kdb.so der Bindungen)
• runner ...eine ausführbare Datei, die lib zur Laufzeit mit dlopen lädt (wie lua/python)

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

Dieses Szenario funktioniert unter Linux, schlägt jedoch unter FreeBSD fehl.

Ich weiß, dass RPATH in einer Bibliothek nicht portierbar ist (es funktionierte auch nicht für musl). Aber es schien für Mac OS X zu funktionieren ( @mpranj berichtete auch, dass testkdb*-Tests gut funktionieren und @omnidan berichtete, dass kdb mit Mac OS X funktioniert). Daher habe ich darum gebeten, zu untersuchen, warum nur die Python / Lua-Tests fehlschlagen.

Der portable Weg, Elektra zu installieren, besteht nicht darin, TARGET_PLUGIN_FOLDER und für Tests könnten wir (wie vorgeschlagen) LD_LIBRARY_PATH . (Wir müssten es nur in run_memcheck und run_all setzen).

@mpranj berichtete auch, dass testkdb*-Tests gut funktionieren und @omnidan berichtete, dass kdb mit Mac OS X funktioniert

testkdb* und kdb haben DT_RPATH selbst gesetzt. Python und Lua-Interpreter nicht. Das ist grundlegend anders.

[...] und für Tests könnten wir (wie vorgeschlagen) LD_LIBRARY_PATH verwenden.

Dann füge es bitte hinzu. Vielen Dank

Ja, Sie haben Recht für das Build-System: CMake scheint RPATH für jede ausführbare Datei zu setzen, aber offensichtlich nicht für Python/lua.

Wenn es installiert ist, wird es jedoch nicht eingestellt. Also bitte bestätigt jemand, ob kdb funktioniert (mit TARGET_PLUGIN_FOLDER gesetzt).

@sanssecours können Sie BUILD_STATIC und BUILD_FULL deaktivieren und alle ( testkdb ) Tests erneut ausführen?

Das ändert sich anscheinend nicht so sehr, außer dass ninja test weniger Tests durchführt (54 statt 114). Die Tests test_kdb.lua und testpy2_kdb.py schlagen immer noch fehl. Alle anderen Tests (scheinen) zu funktionieren.

https://cmake.org/Wiki/CMake_RPATH_handling sagt ".. RPATH on Mac OS X. Es wird sowohl für den Build-Tree als auch für den Installations-Tree aktiviert", also sollten eigentlich auch die Build-Tree-Binärdateien RPATH gesetzt haben. ZB mit readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

Ich habe den Befehl otool -l lib/libelektra-resolver.so — libelektra-core.so.0.8.16 existiert nicht auf meinem Rechner. Laut Ausgabe:

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

RPATH ist eingestellt.

Interessant wäre zB auch kdb run_all (neben dem, was ich oben schon geschrieben habe).

Auf meinem Computer schlagen 5 von 655 Tests fehl. 4 der Tests ( testmod_crypto , testmod_iterate , testmod_semlock und testmod_template ) schlagen aufgrund des gleichen grundlegenden Fehlers fehl:

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

Der Test testmod_python2 zeigt folgende Fehlerausgabe:

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

Unten ist die Ausgabe von testmod_lua , die keine Fehler meldet.

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

Unter OS X werden Dylibs erstellt, nicht .so. Es gibt definitiv eine libelektra-core.0.8.16.dylib oder ähnliches.

Es gibt definitiv eine libelektra-core.0.8.16.dylib oder ähnliches.

Du hast recht. Anscheinend ist RPATH nicht für libelektra-core.0.8.16.dylib , da otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH keine Ausgabe anzeigt.

Don't grep-Ausgabe ist kurz oder grep in Kleinbuchstaben rpath

Don't grep-Ausgabe ist kurz oder grep in Kleinbuchstaben rpath

Meinen Sie "keine grep-Ausgabe, das ist kurz, oder grep in Kleinbuchstaben rpath"? Wenn ja, warum nicht? Ich habe auch nach RPATH in der Ausgabe von otool -l lib/libelektra-core.0.8.16.dylib über die integrierte Suche meiner Terminal-Anwendung gesucht. Dies zeigt auch kein Vorkommen von LC_RPATH .

Wenn ich nach rpath suche, sehe ich ein Vorkommen von @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
...

Soweit ich weiß, ist @rpath nur ein Platzhalter für (die Werte, die in) RPATH gespeichert sind. Ich glaube nicht, dass dieses Vorkommen von rpath uns sagt, ob RPATH gesetzt ist oder nicht.

Laut dem CMake-Wiki ist der Befehl otool -l <file> | grep LC_RPATH -A2 eine Möglichkeit, die RPATHs einer Datei anzuzeigen. Ich denke, die weniger schicke Version, die ich verwendet habe – otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH – sollte auch mehr oder weniger in Ordnung sein.

Leute, warum überprüft ihr das überhaupt?

@sanssecours Entschuldigung, ich habe die Nachricht schnell von meinem Telefon gesendet, also habe ich nicht gesehen, dass es keinen Sinn macht.

Ich bezog mich auf otool -L das die Abhängigkeiten anzeigt und nur @rpath anzeigt. Aber ja, Sie haben Recht. otool -l ist der richtige Befehl.

Übrigens habe ich keine einzige Bibliothek in meinem System gefunden, die RPATH verwendet, außer Elektra.

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

Wie @manuelm jedoch sagt, könnten diese Überprüfungen ziemlich sinnlos sein ...

Ich glaube nicht, dass wir alle oben genannten Probleme vollständig verstehen, aber ich stimme zu, dass die Art von Remote-Debugging, die wir durchführen, nicht effizient ist. Jemand sollte untersuchen und dokumentieren, wie man nicht-glibc-Systeme am besten unterstützt. Lassen Sie uns im Meeting besprechen, wie es weitergeht.

@markus2330 Ich verstehe das Problem voll und ganz. Legen Sie LD_LIBRARY_PATH fest, bevor die Tests beginnen, und ich verspreche, dass das Problem behoben ist.

Alle anderen genannten Probleme sind Ablenkungsmanöver oder einfach nur falsch.

@manuelm Ich wollte nett sein und sagte "wir". Offensichtlich würde der LD_LIBRARY_PATH die Probleme beheben, dass keine Bibliotheken im Build-Verzeichnis gefunden werden (es sei denn, es wird irgendwo zurückgesetzt, was zumindest für Python/lua GI-Tests der Fall zu sein scheint). Aber wenn deine Theorie stimmt, dass RPATH in der Binärdatei gesetzt werden muss, wäre auch die installierte Version kaputt, was derzeit nicht wirklich bestätigt wird. Dies sollte untersucht werden.

Meine Theorie ist nicht mehr nur eine Theorie, weil ich den Beweis erbracht habe.

Noch einmal: Unter Linux funktionieren die Bindungen, weil die Bibliothek, die die Bindungen implementiert ( kdb.so für lua/python und libgelektra-4.0.so für glib) DT_RPATH gesetzt hat _AND_ dlopen ehrt dies.

Natürlich funktionieren die Bindungen, nachdem elektra in die globalen Systembibliothekspfade installiert wurde. Ich sehe absolut keinen Grund, warum das plötzlich nicht mehr funktionieren sollte.

Die Tests der Bindungen funktionieren nicht für !=linux. Das ist alles.

PS: Ich weiß, dass die GI-Bindungstests LD_LIBRARY_PATH erfordern. Deshalb wollte ich, dass Sie eine Art Build-System-Makro hinzufügen, das den GI-Fall integriert/anhängt.

Es scheint, dass die Bindungstests der einzige Ort sind, an dem der LD_LIBRARY_PATH benötigt wird, also habe ich ihn genau dort hinzugefügt.

@mpranj Hoffentlich bekommen wir bald einen Travis, der bestätigen kann, ob es funktioniert?

@markus2330 nein, es funktioniert nicht. (weder auf travis noch auf meiner Maschine)

@mpranj danke fürs testen. Haben Sie die travis-Datei bereit, um sie erneut zu testen, ohne jemanden zu stören? Beide Testfälle scheitern immer noch? Habe ich LD_LIBRARY_PATH irgendwo vergessen oder funktioniert der Ansatz einfach nicht?

@markus2330 ja, ich

Sie können es hier sehen: https://travis-ci.org/mpranj/libelektra
Und btw scheint es , wie @manuelm war ziemlich viel mit TRAVIS + OS X. getan Die Tests versagen aber travis ist eigentlich fast vollständig aufgebaut denke ich.

Ja, das hat er gesagt. Hauptsächlich fehlte das Matrix-Setup, um Mac OS X und andere mit einer Travis-Datei zu erstellen.

Vielen Dank für Ihre Hilfe, das Problem sollte jetzt behoben sein.