libelektra 🚀 - Beberapa Tes Gagal di OS X

Maaf tapi saya tidak punya OS X. Namun ctest -V adalah teman Anda.

manuelm pada 26 Apr 2016

👍1

btw memanggil lua $file tidak sama dengan menjalankan tes. Anda menggunakan perpustakaan kdb yang diinstal sistem sementara pengujian jelas menggunakan perpustakaan yang terletak di direktori build. Anda setidaknya harus menetapkan LUA_CPATH . lihat https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/swig/lua/tests/CMakeLists.txt#L12

90% dari kerusakan terkait swig terkait dengan kesalahan lingkungan build. Jadi pertama-tama coba regenerate(!) + kompilasi ulang binding swig.

manuelm pada 26 Apr 2016

Masalah ini mungkin terkait dengan ad537b3 (setidaknya di Linux kdb*lua|python mogok, tetapi perbaikan untuk Linux adalah bagian dari ad537b3). Tanpa hasil tes, seseorang tidak dapat benar-benar mengetahuinya.

Anda dapat menggunakan make run_all yang menekan keluaran dari kasus uji yang berhasil tetapi menampilkan keluaran untuk kasus yang gagal.

markus2330 pada 26 Apr 2016

@sanssecours Adakah pembaruan tentang ini?

manuelm pada 9 Mei 2016

Masalah ini mungkin terkait dengan ad537b3 (setidaknya di Linux kdb*lua|python mogok, tetapi perbaikan untuk Linux adalah bagian dari ad537b3). Tanpa hasil tes, seseorang tidak dapat benar-benar mengetahuinya.
@sanssecours Adakah pembaruan tentang ini?

Maaf untuk respon yang terlambat. Saya pikir saya sudah menulis komentar yang berisi informasi tambahan tentang masalah ini. Mari saya mulai dengan mengatakan bahwa testpy2_kdb.py juga gagal pada mesin saya. Jadi mungkin ada masalah dengan pengaturan khusus saya. Saya menginstal SWIG melalui Homebrew dan saat ini menggunakan perintah cmake untuk menghasilkan file build untuk Elektra:

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

Berikut adalah output dari 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

Sepertinya Lua tidak dapat menemukan libelektra-resolver.so , yang terletak di build/lib dan /usr/local/lib/elektra pada mesin saya. Apakah saya perlu mengatur beberapa jalur perpustakaan agar ini berfungsi? Omong-omong, sepertinya testpy2_kdb.py juga gagal karena masalah yang sama persis.

sanssecours pada 9 Mei 2016

Binding tidak memuat pustaka elektra apa pun saat runtime. Mereka hanya pengikat. Anda dapat melihat ini dengan melihat lokasi kesalahan yang tepat, yaitu ../src/libs/loader/dl.c:82 .

Jadi ini adalah masalah dengan lingkungan Anda, masalah elektra umum di OSX atau masalah sistem build di OSX. Saya mencurigai mantan. ping ke @markus2330

manuelm pada 9 Mei 2016

dlopen(libelektra-resolver.so, 2): image not found sebenarnya sepertinya tidak ada hubungannya dengan lua.

libelektra-resolver.so harus menjadi symlink ke resolver yang Anda pilih dengan KDB_DEFAULT_RESOLVER , mungkin pengaturan/instalasi Anda rusak? Bisakah Anda memeriksa apakah symlink sudah benar?

Anehnya adalah: libelektra-resolver.so digunakan dalam setiap kasus uji terkait kdb, mengapa hanya _not_ yang berfungsi dalam kasus uji ini? Mungkin test case ini (dan yang python) menggunakan pustaka yang diinstal dan bukan pustaka di direktori build. Bisakah Anda memeriksa dengan strace libelektra-resolver.so mana yang coba dimuat oleh kasus uji?

image not found cukup umum, mungkinkah di dalam perpustakaan gambar untuk arsitektur Anda tidak ditemukan? Apakah Anda menggunakan binari lemak ?

markus2330 pada 9 Mei 2016

libelektra-resolver.so harus menjadi symlink ke resolver yang Anda pilih dengan KDB_DEFAULT_RESOLVER , mungkin pengaturan/instalasi Anda rusak?

Apakah ada cara mudah untuk memeriksa apakah instalasi Elektra lokal rusak? Perintah kdb tampaknya berfungsi.

Bisakah Anda memeriksa apakah symlink sudah benar?

Kedua alias libelektra-resolver.so menautkan ke file libelektra-resolver_fm_hpu_b.so terletak di direktori yang sama dengan alias. Jadi sepertinya mereka benar.

Bisakah Anda memeriksa dengan strace libelektra-resolver.so mana yang coba dimuat oleh kasus uji?

Saya mencoba sudo dtruss ctest -V -R test_kdb.lua . Berikut adalah outputnya:
test_kdb.lua - dtruss Output.txt . Sepertinya pengujian menggunakan versi Elektra di direktori build. Saya mencopot pemasangan Elektra melalui sudo ninja uninstall . Saya kemudian menjalankan tes lagi. Outputnya masih sama.

Apakah Anda menggunakan binari lemak?

Bukannya aku sadar.

sanssecours pada 9 Mei 2016

Apakah Anda menggunakan OSX El Capitan? Ini mungkin masalah Perlindungan Integritas Sistem yang aneh.

markus2330 pada 9 Mei 2016

Agak aneh bahwa kdb berfungsi.

manuelm pada 9 Mei 2016

Jika ada hubungannya dengan Perlindungan Integritas Sistem karena instalasi python/lua mungkin masuk akal.

markus2330 pada 9 Mei 2016

Apakah Anda menggunakan OSX El Capitan? Ini mungkin masalah Perlindungan Integritas Sistem yang aneh.

Ya, saya menggunakan OS X 10.11.4. Saya menonaktifkan SIP untuk sementara dan menjalankan tes lagi. Masih masalah yang sama. Meskipun, setelah saya menonaktifkan SIP, saya menemukan tes baru yang gagal: testscr_check_kdb_internal_suite . Dan sekarang testscr_check_merge juga tidak berfungsi lagi .

Saya kembali ke 0.8.16, membersihkan direktori build saya dan menjalankan ninja test lagi. Baik testscr_check_kdb_internal_suite dan testscr_check_merge masih gagal, meskipun saya ingat, setidaknya testscr_check_kdb_internal_suite bekerja ketika Elektra 0.8.16 dirilis. Berikut adalah output dari tes tambahan yang gagal sekarang juga:
tescr_check_kdb_internal_suite.txt
tescr_check_merge.txt

sanssecours pada 10 Mei 2016

Saya telah mengubah judul dan menghapus diri saya sendiri. Saya tidak memiliki akses langsung ke mesin OSX dan tidak memiliki pengetahuan yang mendalam. Tanpa mesin untuk melihat-lihat, saya tidak dapat membedakan apa pun dari output teks.

manuelm pada 10 Mei 2016

Apakah Anda juga melihat petunjuk lain dari tautan? Misalnya menginstal ulang python/lua?

@petermax2 @mpranj Bisakah Anda mereproduksi masalah ini?

markus2330 pada 10 Mei 2016

Apakah Anda juga melihat petunjuk lain dari tautan? Misalnya menginstal ulang python/lua?

Maaf, tidak juga. Instalasi Python 2 adalah yang disertakan dengan sistem. Untuk menginstal ulang, saya harus menginstal ulang seluruh sistem operasi.

Saya hanya menginstal Lua hanya untuk menguji plugin Lua Elektra. Jadi saya tidak berpikir bahwa menginstal ulang masuk akal. Namun, karena hanya membutuhkan beberapa detik, saya mengeksekusi brew reinstall lua . Setelah itu saya mulai dengan direktori build yang bersih, menjalankan perintah build dan ctest -VV -R test_kdb.lua . Tes masih menunjukkan output yang sama.

Omong-omong: Tes testscr_check_kdb_internal_suite dan testscr_check_merge sekarang juga berfungsi dengan benar lagi, setelah saya menghapus semua file dari /etc/kdb .

sanssecours pada 10 Mei 2016

Saat ini saya tidak punya ide lain. (kecuali isolasi masalah yang memakan waktu: untuk mengurangi panggilan dlopen menjadi contoh minimal di mana itu tidak akan berfungsi) Jadi mungkin lebih baik menunggu jika seseorang dapat mereproduksi masalah, mungkin itu menyinari masalah baru.

markus2330 pada 10 Mei 2016

👍1

Saya dapat mengkonfirmasi perilaku yang sama pada mesin saya.

Solusi: atur jalur perpustakaan dengan benar: mis
LD_LIBRARY_PATH="/Users/mpranj/workspace/libelektra/build/lib" ctest -V -R test_kdb.lua berfungsi dengan baik untuk saya.

dlopen pada OS X mencari $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH , saya pikir dalam urutan itu.

PR #710 memperbaikinya, namun saya tidak yakin apakah perbaikannya sangat bersih.

mpranj pada 10 Mei 2016

❤1

Tidak, perbaikannya pasti tidak bersih.

Sejauh yang saya ingat, pengujian kami bergantung pada DT_RPATH yang diatur dalam libelektra-kdb.so . Jika ini tidak tersedia di OSX, kita harus mendefinisikannya di beberapa tempat lingkungan build global.

Sunting: Tapi terima kasih telah mencari tahu!

manuelm pada 10 Mei 2016

RPATH disetel untuk semua pustaka inti, tetapi mungkin libelektra-core sudah cukup: di tempat ini dlopen terjadi.

Apakah image not found berarti perpustakaan tidak ditemukan? Jika demikian, adakah ide mengapa RPATH bekerja untuk semua kecuali tes lua dan python?

markus2330 pada 10 Mei 2016

Sekadar informasi: Elektra juga mendukung sistem tanpa RPATH (misalnya openwrt dengan musl sebagai libc) hanya dengan menyetel TARGET_PLUGIN_FOLDER ke string kosong.

markus2330 pada 10 Mei 2016

Tampaknya hal serupa terjadi di 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:

Belum bisa cek lua di FreeBSD.

mpranj pada 10 Mei 2016

@mpranj baik untuk diketahui, jadi FreeBSD tampaknya menjadi petunjuk yang baik jika bekerja dengan MacOSX juga (di sebelah OpenBSD). Apakah testcase kdb dan alat baris perintah kdb berfungsi?

Bisakah Anda membuka masalah atau menambahkan masalah OpenBSD tentang kasus uji yang tidak bekerja di FreeBSD?

markus2330 pada 10 Mei 2016

Jika maksud Anda ini:

        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

... lalu ya. Alat kdb tampaknya berfungsi (hanya pemeriksaan cepat dengan ls).

Kalau tidak, banyak hal yang gagal tetapi saya tidak akan dapat memeriksa/melaporkan semuanya hari ini. Tapi tentu saja saya akan melaporkan semuanya ketika saya mengujinya dengan benar.

mpranj pada 10 Mei 2016

Dugaan saya adalah tes kdb berfungsi karena ditautkan secara statis, bukan?
Jika saya menonaktifkan BUILD_STATIC tes juga tidak berfungsi.

@ markus2330 Saya tidak berpikir kita dapat menghindari pengaturan LD_LIBRARY_PATH pada beberapa platform. Bagaimana cara kerja TARGET_PLUGIN_FOLDER ? Atau lebih spesifik bagaimana ini menyelesaikan pencarian perpustakaan dinamis?

manuelm pada 12 Mei 2016

Terima kasih itu ide yang bagus: @sanssecours dapatkah Anda menonaktifkan BUILD_STATIC dan BUILD_FULL dan menjalankan kembali semua ( testkdb ) tes?

Jika TARGET_PLUGIN_FOLDER kosong, plugin dipasang di tempat perpustakaan berada dan tidak diperlukan RPATH atau LD_LIBRARY_PATH . Tapi itu hanya akan membantu ketika Elektra yang diinstal digunakan (yang mungkin terjadi untuk tes python / lua ).

https://cmake.org/Wiki/CMake_RPATH_handling mengatakan ".. RPATH di Mac OS X. Ini akan diaktifkan untuk pohon build dan menginstal pohon", jadi sebenarnya juga binari pohon build harus memiliki set RPATH. @sanssecours Bisakah Anda memeriksa ini? Misalnya menggunakan readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

markus2330 pada 15 Mei 2016

Masalahnya bukan tentang RPATH itu sendiri, tetapi tentang dlopen di linux membaca DT_RPATH vs. platform lain.

man dlopen dari glibc:

(Khusus ELF) Jika file yang dapat dieksekusi untuk program panggilan berisi tag DT_RPATH, dan tidak berisi tag DT_RUNPATH, maka direktori yang terdaftar dalam tag DT_RPATH akan dicari.
Jika, pada saat program dimulai, variabel lingkungan LD_LIBRARY_PATH didefinisikan berisi daftar direktori yang dipisahkan titik dua, maka direktori ini akan dicari. (Sebagai ukuran keamanan, variabel ini diabaikan untuk program set-user-ID dan set-group-ID.)
(Khusus ELF) Jika file yang dapat dieksekusi untuk program panggilan berisi tag DT_RUNPATH, maka direktori yang terdaftar dalam tag tersebut akan dicari.
File cache /etc/ld.so.cache (dimainkan oleh ldconfig(8)) diperiksa untuk melihat apakah file tersebut berisi entri untuk nama file.
Direktori /lib dan /usr/lib dicari (dalam urutan itu).

man dlopen di OSX:

Ketika jalur tidak berisi karakter garis miring (yaitu hanya nama daun), dlopen() mencari yang berikut ini hingga menemukan file Mach-O yang kompatibel: $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, direktori kerja saat ini, $DYLD_FALLBACK_LIBRARY_PATH.

manuelm pada 15 Mei 2016

dlopen harus bekerja dengan jalur absolut di sini, atau harus di salah satu jalur yang disebutkan di atas

mpranj pada 15 Mei 2016

Tapi kami tidak melakukan jalur absolut. Jadi tidak tahu bagaimana informasi ini membantu

manuelm pada 15 Mei 2016

RPATH absolut atau jalur absolut ke plugin? CMake mengklaim memiliki dukungan untuk RPATH build-tree, sehingga harus menggunakan RPATH absolut jika diperlukan.

Jalur absolut ke plugin adalah apa yang dilakukan banyak orang dan itu akan menjadi perubahan yang mudah, tetapi saya tidak melihat bagaimana itu tidak akan membantu untuk kasus uji bawaan.

Pertama akan menarik apa masalah sebenarnya di sini. Apakah versi yang diinstal benar-benar berfungsi sepenuhnya? Misalnya kdb run_all akan menarik juga (sebelah apa yang saya tulis di atas sudah).

markus2330 pada 15 Mei 2016

Tempel saya dari halaman manual dlopen dengan jelas menyatakan tentang apa masalahnya.
Jalur pencarian dlopen(libelektra-resolver.so) berbeda pada platform yang berbeda. Linux berfungsi karena dlopen menghormati DT_RPATH dari libelektra-kdb.so

manuelm pada 15 Mei 2016

Tampaknya pengaturan LD_LIBRARY_PATH adalah apa yang juga dilakukan katup.
https://github.com/ValveSoftware/steam-runtime/blob/master/runtime/run.sh

mpranj pada 15 Mei 2016

Maksud Anda masalahnya adalah mereka tidak menulis dokumentasi? @rpath bahkan tidak disebutkan di sana.

Saya pikir sampai kita tidak tahu apa yang sebenarnya berfungsi ketika diinstal/dengan BUILD_SHARED kita tidak boleh berspekulasi lebih lanjut.

markus2330 pada 15 Mei 2016

@markus2330
EDIT: menonaktifkan BUILD_STATIC dan BUILD_FULL:
tes testkdb* berjalan dengan baik.

mpranj pada 15 Mei 2016

Tentang dokumentasi, mereka menyebutkan @rpath sini .

mpranj pada 15 Mei 2016

Baru saja memverifikasi pernyataan saya dengan contoh singkat:

runtimelib ...pustaka yang menyediakan beberapa fungsi acak. (seperti elektra-resolver)
lib ...sebuah perpustakaan yang memuat runtimelib saat runtime menggunakan dlopen . Ini memiliki DT_RPPATH yang disetel ke direktori runtimelib . (seperti kdb.so dari binding)
runner ...sebuah executable yang memuat lib saat runtime menggunakan dlopen (seperti lua/python)

Lihat https://Gist.github.com/manuelm/43a4fa9dd424b4dcf03bd1d773a0e122

Skenario ini bekerja di Linux, tetapi gagal di FreeBSD.

manuelm pada 15 Mei 2016

Saya tahu bahwa RPATH yang diatur di perpustakaan tidak portabel (itu juga tidak berfungsi untuk musl). Tetapi tampaknya berfungsi untuk Mac OS X ( @mpranj juga melaporkan bahwa tes testkdb* berfungsi dengan baik dan @omnidan melaporkan kdb berfungsi dengan Mac OS X). Jadi saya meminta untuk menyelidiki mengapa hanya tes python/lua yang gagal.

Cara portabel untuk menginstal Elektra tidak mengatur TARGET_PLUGIN_FOLDER dan untuk pengujian kita dapat menggunakan (seperti yang disarankan) LD_LIBRARY_PATH . (Kita hanya perlu mengaturnya di dalam run_memcheck dan run_all).

markus2330 pada 15 Mei 2016

@mpranj juga melaporkan bahwa tes testkdb* berfungsi dengan baik dan @omnidan melaporkan

testkdb* dan kdb telah DT_RPATH mengaturnya sendiri. Python dan juru lua belum. Itu berbeda secara fundamental.

[...] dan untuk tes kita bisa menggunakan (seperti yang disarankan) LD_LIBRARY_PATH.

Kemudian silahkan tambahkan. Terima kasih

manuelm pada 15 Mei 2016

Ya, Anda benar untuk sistem pembangunan: CMake tampaknya mengatur RPATH pada setiap yang dapat dieksekusi, tetapi jelas tidak untuk python/lua.

Namun, saat dipasang, itu tidak akan disetel. Jadi tolong seseorang mengkonfirmasi jika kdb berfungsi (dengan set TARGET_PLUGIN_FOLDER ).

markus2330 pada 15 Mei 2016

@sansecours dapatkah Anda menonaktifkan BUILD_STATIC dan BUILD_FULL dan menjalankan kembali semua ( testkdb ) tes?

Sepertinya ini tidak banyak berubah, kecuali bahwa ninja test menjalankan lebih sedikit tes (54 bukannya 114). Pengujian test_kdb.lua dan testpy2_kdb.py masih gagal. Semua tes lain (tampaknya) berfungsi.

https://cmake.org/Wiki/CMake_RPATH_handling mengatakan ".. RPATH di Mac OS X. Ini akan diaktifkan untuk pohon build dan menginstal pohon", jadi sebenarnya juga binari pohon build harus memiliki set RPATH. Misalnya menggunakan readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

Saya menggunakan perintah otool -l lib/libelektra-resolver.so — libelektra-core.so.0.8.16 tidak ada di mesin saya. Menurut keluarannya:

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

RPATH disetel.

Misalnya kdb run_all akan menarik juga (di samping apa yang saya tulis di atas).

Di mesin saya 5 dari 655 tes gagal. 4 tes ( testmod_crypto , testmod_iterate , testmod_semlock dan testmod_template ) gagal karena kesalahan dasar yang sama:

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

Tes testmod_python2 menunjukkan output kesalahan berikut:

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

Di bawah ini adalah output dari testmod_lua , yang melaporkan tidak ada kesalahan.

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

sanssecours pada 16 Mei 2016

Di OS X, dylib dibuat, bukan .so. Pasti ada libelektra-core.0.8.16.dylib atau yang serupa.

mpranj pada 16 Mei 2016

Pasti ada libelektra-core.0.8.16.dylib atau yang serupa.

Kamu benar. Sepertinya RPATH tidak disetel untuk libelektra-core.0.8.16.dylib , karena otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH tidak menampilkan output.

sanssecours pada 16 Mei 2016

Jangan grep output pendek, atau grep rpath huruf kecil

mpranj pada 16 Mei 2016

Jangan grep output pendek, atau grep rpath huruf kecil

Maksud Anda "Jangan grep output, itu pendek, atau grep rpath huruf kecil"? Jika demikian, mengapa tidak? Saya juga mencari RPATH di output otool -l lib/libelektra-core.0.8.16.dylib melalui pencarian built-in dari aplikasi Terminal saya. Ini juga tidak menunjukkan kemunculan LC_RPATH .

Jika saya mencari rpath , maka saya melihat satu kemunculan @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
...

Sejauh yang saya tahu @rpath hanya pengganti untuk (nilai yang disimpan di) RPATH . Saya tidak berpikir bahwa kemunculan rpath memberi tahu kita apakah RPATH disetel atau tidak.

Menurut wiki CMake perintah otool -l <file> | grep LC_RPATH -A2 adalah salah satu cara yang mungkin untuk menampilkan RPATH dari beberapa file. Saya pikir versi yang kurang mewah yang saya gunakan – otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH – harus lebih atau kurang baik juga.

sanssecours pada 16 Mei 2016

Kawan, mengapa Anda memeriksa ini sama sekali?

manuelm pada 16 Mei 2016

@sansecours maaf, saya mengirim pesan dengan cepat dari ponsel saya, jadi saya tidak melihat itu tidak masuk akal.

Saya merujuk ke otool -L yang menunjukkan dependensi dan hanya menampilkan @rpath . Tapi ya Anda benar otool -l adalah perintah yang tepat.

Btw saya belum menemukan satu perpustakaan pun di sistem saya yang menggunakan RPATH, kecuali elektra.

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

Seperti yang dinyatakan @manuelm , pemeriksaan ini mungkin tidak ada gunanya...

mpranj pada 16 Mei 2016

Saya rasa kami tidak sepenuhnya memahami semua masalah di atas, tetapi saya setuju bahwa jenis debugging jarak jauh yang kami lakukan tidak efisien. Seseorang harus menyelidiki dan mendokumentasikan apa cara terbaik untuk mendukung sistem non-glibc. Mari kita bahas dalam pertemuan bagaimana untuk melanjutkan.

markus2330 pada 16 Mei 2016

@ markus2330 Saya sepenuhnya memahami masalah ini. Setel LD_LIBRARY_PATH sebelum tes dimulai dan saya berjanji masalah ini hilang.

Semua masalah lain yang disebutkan adalah ikan haring merah atau hanya salah.

manuelm pada 16 Mei 2016

@manuelm Saya ingin bersikap baik dan berkata "kami". Jelas LD_LIBRARY_PATH akan memperbaiki masalah tidak menemukan perpustakaan di direktori build (kecuali jika disetel ulang di suatu tempat, yang tampaknya menjadi kasus setidaknya untuk pengujian python/lua GI). Tetapi jika teori Anda benar bahwa RPATH harus diatur dalam biner, juga versi yang diinstal akan rusak, yang saat ini tidak benar-benar dikonfirmasi. Ini harus diselidiki.

markus2330 pada 16 Mei 2016

Teori saya bukan sekedar teori lagi, karena saya sudah membuktikannya.

Sekali lagi: Di linux binding berfungsi karena perpustakaan mengimplementasikan binding ( kdb.so untuk lua/python dan libgelektra-4.0.so untuk glib) memiliki DT_RPATH set _AND_ dlopen menghormati ini.

Tentu saja binding akan berfungsi setelah elektra diinstal ke jalur pustaka sistem global. Saya benar-benar tidak melihat alasan mengapa ini tiba-tiba berhenti bekerja.

Pengujian binding tidak berfungsi untuk !=linux. Itu saja.

manuelm pada 16 Mei 2016

PS: Saya tahu tes binding GI membutuhkan LD_LIBRARY_PATH. Itu sebabnya saya ingin Anda menambahkan semacam makro sistem build yang mengintegrasikan/menambahkan case GI.

manuelm pada 16 Mei 2016

Sepertinya tes pengikatan adalah satu-satunya tempat di mana LD_LIBRARY_PATH diperlukan, jadi saya menambahkannya di sana.

@mpranj Semoga kita segera mendapatkan travis yang bisa mengkonfirmasi jika berhasil?

markus2330 pada 19 Mei 2016

@ markus2330 tidak, itu tidak berfungsi. (tidak di travis atau di mesin saya)

mpranj pada 21 Mei 2016

@mpranj terima kasih atas pengujiannya. Apakah Anda memiliki file travis yang siap untuk mengujinya lagi tanpa mengganggu seseorang? Kedua kasus uji masih gagal? Apakah saya lupa LD_LIBRARY_PATH di suatu tempat atau pendekatannya tidak berfungsi?

markus2330 pada 21 Mei 2016

@ markus2330 ya saya sedang menguji di travis, tetapi sebagian besar memiliki perilaku yang sama seperti di mesin saya. Sepertinya da243f9e25d8fa14f8286c48b4338a73c1e7242d tidak membuat perbedaan.

mpranj pada 21 Mei 2016

Anda dapat melihatnya di sini: https://travis-ci.org/mpranj/libelektra
Dan btw sepertinya @manuelm sudah cukup banyak dilakukan dengan travis+OS X.

mpranj pada 21 Mei 2016

Ya, dia mengatakan itu. Terutama pengaturan matriks untuk membangun Mac OS X dan lainnya dengan satu file travis hilang.

markus2330 pada 21 Mei 2016

Terima kasih atas semua bantuan Anda, masalah harus diperbaiki sekarang.

markus2330 pada 31 Mei 2016

Libelektra: Beberapa Tes Gagal di OS X

Semua 57 komentar

Masalah terkait