Libelektra: OS X पर कुछ परीक्षण विफल हो जाते हैं

मुझे खेद है, लेकिन मेरे पास OS X नहीं है। हालांकि ctest -V आपका मित्र है।

बीटीडब्ल्यू lua $file को कॉल करना परीक्षण चलाने जैसा नहीं है। आप सिस्टम स्थापित kdb लाइब्रेरी का उपयोग कर रहे हैं, जबकि परीक्षण स्पष्ट रूप से बिल्ड डायरेक्टरी में स्थित लाइब्रेरी का उपयोग कर रहे हैं। आपको कम से कम LUA_CPATH सेट करना चाहिए। देखें https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/swig/lua/tests/CMakeLists.txt#L12

स्विग से संबंधित 90% दुर्घटनाएं बिल्ड एनवायरनमेंट फॉल्ट से संबंधित थीं। तो पहले पुन: उत्पन्न करने का प्रयास करें (!) + स्विग बाइंडिंग को पुन: संकलित करें।

यह समस्या ad537b3 से संबंधित हो सकती है (कम से कम Linux kdb*lua|python पर क्रैश हो रहा था, लेकिन Linux के लिए फिक्स ad537b3 का हिस्सा है)। परीक्षण के आउटपुट के बिना कोई वास्तव में नहीं बता सकता है।

आप make run_all उपयोग कर सकते हैं जो सफल परीक्षण मामलों के आउटपुट को दबा देता है लेकिन असफल लोगों के लिए आउटपुट दिखाता है।

@sanssecours इस पर कोई अपडेट?

यह समस्या ad537b3 से संबंधित हो सकती है (कम से कम Linux kdb*lua|python पर क्रैश हो रहा था, लेकिन Linux के लिए फिक्स ad537b3 का हिस्सा है)। परीक्षण के आउटपुट के बिना कोई वास्तव में नहीं बता सकता है।

@sanssecours इस पर कोई अपडेट?

देरी से जवाब देने के लिए माफी। मुझे लगा कि मैंने पहले ही इस मुद्दे के बारे में विस्तृत जानकारी वाली एक टिप्पणी लिखी है। मुझे यह कहकर शुरू करना चाहिए कि मेरी मशीन पर testpy2_kdb.py भी विफल रहता है। तो यह मेरे विशिष्ट सेटअप के साथ एक समस्या हो सकती है। मैंने Homebrew के माध्यम से SWIG स्थापित किया है और वर्तमान में Elektra के लिए बिल्ड फाइल बनाने के लिए निम्नलिखित cmake कमांड का उपयोग करता हूं:

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

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

ऐसा लगता है कि लुआ को libelektra-resolver.so , जो मेरी मशीन पर build/lib और /usr/local/lib/elektra । क्या मुझे इसके लिए काम करने के लिए कुछ पुस्तकालय पथ निर्धारित करने की आवश्यकता है? वैसे, ऐसा लगता है कि testpy2_kdb.py भी उसी सटीक समस्या के कारण विफल हो जाता है।

बाइंडिंग रनटाइम पर किसी भी इलेक्ट्रा लाइब्रेरी को लोड नहीं करती है। वे सिर्फ बंधन हैं। आप इसे सटीक त्रुटि स्थान को देखकर देख सकते हैं, जो कि ../src/libs/loader/dl.c:82 ।

तो यह या तो आपके पर्यावरण के साथ एक मुद्दा है, ओएसएक्स पर एक सामान्य इलेक्ट्रा मुद्दा या ओएसएक्स पर एक बिल्ड सिस्टम समस्या है। मुझे पूर्व पर संदेह है। पिंग @markus2330

dlopen(libelektra-resolver.so, 2): image not found वास्तव में ऐसा लगता है कि इसका लुआ से कोई लेना-देना नहीं है।

libelektra-resolver.so आपके द्वारा चुने गए रिज़ॉल्वर के लिए एक सिमलिंक होना चाहिए KDB_DEFAULT_RESOLVER , हो सकता है कि आपका सेटअप/इंस्टॉलेशन टूट गया हो? क्या आप जांच सकते हैं कि सिम्लिंक सही हैं या नहीं?

अजीब बात है: libelektra-resolver.so का उपयोग प्रत्येक केडीबी से संबंधित परीक्षण मामले में किया जाता है, यह केवल _not_ इस परीक्षण मामले में क्यों काम कर रहा है? हो सकता है कि यह टेस्ट केस (और पायथन एक) स्थापित लाइब्रेरी का उपयोग करे, न कि बिल्ड डायरेक्टरी में लाइब्रेरी का। क्या आप स्ट्रेस से जांच सकते हैं कि कौन सा libelektra-resolver.so परीक्षण केस लोड करने का प्रयास करता है?

image not found काफी सामान्य है, यह हो सकता है कि पुस्तकालय के भीतर आपकी वास्तुकला की छवि नहीं मिली हो? क्या आप वसा बायनेरिज़ का उपयोग करते हैं?

libelektra-resolver.so आपके द्वारा चुने गए रिज़ॉल्वर के लिए एक सिमलिंक होना चाहिए KDB_DEFAULT_RESOLVER , हो सकता है कि आपका सेटअप/इंस्टॉलेशन टूट गया हो?

क्या यह जांचने का कोई आसान तरीका है कि स्थानीय इलेक्ट्रा इंस्टॉलेशन टूटा हुआ है या नहीं? आदेश kdb काम करता प्रतीत होता है।

क्या आप जांच सकते हैं कि सिम्लिंक सही हैं या नहीं?

दोनों libelektra-resolver.so उपनाम एक फ़ाइल से लिंक करते हैं libelektra-resolver_fm_hpu_b.so उपनाम के रूप में एक ही निर्देशिका में स्थित है। तो ऐसा लगता है कि वे सही हैं।

क्या आप स्ट्रेस से जांच सकते हैं कि कौन सा libelektra-resolver.so परीक्षण केस लोड करने का प्रयास करता है?

मैंने कोशिश की sudo dtruss ctest -V -R test_kdb.lua । यहाँ आउटपुट है:
test_kdb.lua - dtruss Output.txt । ऐसा लगता है कि परीक्षण बिल्ड निर्देशिका में इलेक्ट्रा संस्करण का उपयोग करता है। मैंने sudo ninja uninstall माध्यम से Elektra को अनइंस्टॉल कर दिया। मैंने फिर परीक्षण चलाया। आउटपुट अभी भी वही है।

क्या आप वसा बायनेरिज़ का उपयोग करते हैं?

ऐसा नहीं कि मुझे पता नहीं।

क्या आप OSX El Capitan का उपयोग करते हैं? यह एक अजीब सिस्टम इंटीग्रिटी प्रोटेक्शन समस्या हो सकती

यह अजीब तरह का है कि kdb हालांकि काम करता है।

अगर इसे पाइथन/लुआ इंस्टॉलेशन के कारण सिस्टम इंटीग्रिटी प्रोटेक्शन के साथ करना है तो यह समझ में आ सकता है।

क्या आप OSX El Capitan का उपयोग करते हैं? यह एक अजीब सिस्टम इंटीग्रिटी प्रोटेक्शन समस्या हो सकती है।

हां, मैं ओएस एक्स 10.11.4 का उपयोग करता हूं। मैंने एसआईपी को अस्थायी रूप से अक्षम कर दिया और फिर से परीक्षण चलाया। अभी भी वही समस्या। हालांकि, एसआईपी को अक्षम करने के बाद, मुझे एक नए परीक्षण का सामना करना पड़ा जो विफल हो गया: testscr_check_kdb_internal_suite । और अब testscr_check_merge भी अब काम नहीं करता .

मैं 0.8.16 पर वापस गया, अपनी बिल्ड डायरेक्टरी को साफ किया और फिर से ninja test चलाया। testscr_check_kdb_internal_suite और testscr_check_merge अभी भी विफल हैं, हालांकि मुझे याद आया, कि Elektra 0.8.16 जारी होने पर कम से कम testscr_check_kdb_internal_suite काम करता था। यहाँ अतिरिक्त परीक्षण का आउटपुट है जो अब भी विफल हो जाता है:
testscr_check_kdb_internal_suite.txt
testscr_check_merge.txt

मैंने शीर्षक बदल दिया है और खुद को हटा लिया है। मेरे पास OSX मशीन तक सीधी पहुंच नहीं है और इसमें गहन ज्ञान की कमी है। एक मशीन के बिना चारों ओर प्रहार करने के लिए मैं टेक्स्ट आउटपुट से कुछ नहीं बता सकता।

क्या आपने लिंक के अन्य संकेतों को भी देखा? जैसे अजगर/लुआ को फिर से स्थापित करना?

@ petermax2 @mpranj क्या आप इन मुद्दों को पुन: पेश कर सकते हैं?

क्या आपने लिंक के अन्य संकेतों को भी देखा? जैसे अजगर/लुआ को फिर से स्थापित करना?

क्षमा करें, वास्तव में नहीं। पायथन 2 इंस्टॉलेशन वह है जो सिस्टम के साथ आया था। इसे फिर से स्थापित करने के लिए, मुझे पूरे ऑपरेटिंग सिस्टम को फिर से स्थापित करना होगा।

मैंने केवल लुआ इलेक्ट्रा प्लगइन का परीक्षण करने के लिए लुआ स्थापित किया है। इसलिए मुझे नहीं लगता कि फिर से स्थापित करना ज्यादा मायने रखता है। हालाँकि, चूंकि इसमें केवल कुछ सेकंड लगते हैं, brew reinstall lua मैंने ctest -VV -R test_kdb.lua चलाया। परीक्षण अभी भी वही आउटपुट दिखाता है।

वैसे: परीक्षण testscr_check_kdb_internal_suite और testscr_check_merge अब भी ठीक से काम करते हैं, मेरे द्वारा /etc/kdb से सभी फाइलों को हटाने के बाद।

मेरे पास वर्तमान में दूसरा विचार नहीं है। (समस्या के समय लेने वाली अलगाव को छोड़कर: dlopen कॉल को कम से कम उदाहरण में कम करने के लिए जहां यह काम नहीं करेगा) तो यह इंतजार करना सबसे अच्छा हो सकता है कि कोई इस मुद्दे को पुन: उत्पन्न कर सकता है, शायद यह समस्या पर नई रोशनी चमकता है।

मैं अपनी मशीन पर उसी व्यवहार की पुष्टि कर सकता हूं।

समाधान: पुस्तकालय पथ को सही ढंग से सेट करें: जैसे
LD_LIBRARY_PATH="/Users/mpranj/workspace/libelektra/build/lib" ctest -V -R test_kdb.lua मेरे लिए ठीक काम करता है।

ओएस एक्स पर dlopen खोज $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH , मुझे लगता है कि उस क्रम में।

पीआर # 710 इसे ठीक करता है, हालांकि मुझे यकीन नहीं है कि फिक्स बहुत साफ है।

नहीं, फिक्स निश्चित रूप से साफ नहीं है।

जहां तक ​​मुझे याद है हमारे परीक्षण DT_RPATH में सेट होने पर निर्भर करते हैं libelektra-kdb.so । यदि यह OSX पर उपलब्ध नहीं है तो हमें इसे कुछ वैश्विक बिल्ड एनवायरनमेंट प्लेस में परिभाषित करना चाहिए।

संपादित करें: लेकिन पता लगाने के लिए धन्यवाद!

RPATH सभी मुख्य पुस्तकालयों के लिए सेट है, लेकिन शायद libelektra-core पर्याप्त होना चाहिए: इस स्थान पर dlopen होता है।

क्या image not found सीधा सा मतलब है कि पुस्तकालय नहीं मिला? यदि हां, तो कोई विचार क्यों RPATH लुआ और पायथन परीक्षणों के अलावा सभी के लिए काम करता है?

केवल आपकी जानकारी के लिए: इलेक्ट्रा केवल TARGET_PLUGIN_FOLDER को एक खाली स्ट्रिंग पर सेट करके बिना RPATH (उदा.

ऐसा प्रतीत होता है कि फ्रीबीएसडी बीटीडब्ल्यू पर भी ऐसी ही चीजें होती हैं।

 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:

अभी तक फ्रीबीएसडी पर लुआ की जांच नहीं कर पाए हैं।

@mpranj जानना अच्छा है, इसलिए फ्रीबीएसडी एक अच्छा संकेत प्रतीत होता है अगर यह kdb टेस्टकेस और kdb कमांड-लाइन टूल काम करते हैं?

क्या आप मुद्दों को खोल सकते हैं या उन परीक्षण मामलों के बारे में OpenBSD मुद्दों को जोड़ सकते हैं जो FreeBSD पर काम नहीं करते हैं?

यदि आपका मतलब ये है:

        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

... तो हां। kdb टूल काम करता प्रतीत होता है (एलएस के साथ बस एक त्वरित जांच)।

अन्यथा बहुत सी चीजें विफल हो रही हैं लेकिन मैं आज पूरी जांच/रिपोर्ट नहीं कर पाऊंगा। लेकिन मुझे यकीन है कि जब मैं इसका ठीक से परीक्षण करूंगा तो मैं सब कुछ रिपोर्ट करूंगा।

मेरा अनुमान है कि केडीबी परीक्षण काम करता है क्योंकि वे स्थिर रूप से जुड़े हुए हैं, है ना?
अगर मैं BUILD_STATIC को अक्षम करता हूं तो परीक्षण भी काम नहीं करते हैं।

@markus2330 मुझे नहीं लगता कि हम कुछ प्लेटफॉर्म पर LD_LIBRARY_PATH सेट करने से बच सकते हैं। TARGET_PLUGIN_FOLDER काम कर रहा है? या अधिक विशिष्ट यह गतिशील पुस्तकालय खोज को कैसे हल करता है?

धन्यवाद यह एक अच्छा विचार है: @sanssecours क्या आप BUILD_STATIC और BUILD_FULL को अक्षम कर सकते हैं और सभी ( testkdb ) परीक्षणों को फिर से चला सकते हैं?

यदि TARGET_PLUGIN_FOLDER खाली है, तो प्लग इन स्थापित हैं जहां पुस्तकालय हैं और RPATH या LD_LIBRARY_PATH की आवश्यकता नहीं है। लेकिन यह केवल तभी मदद करता है जब स्थापित इलेक्ट्रा का उपयोग किया जाता है (जो python / lua परीक्षणों के मामले में हो सकता है)।

https://cmake.org/Wiki/CMake_RPATH_handling कहता है ".. मैक ओएस एक्स पर RPATH। यह बिल्ड ट्री और इंस्टाल ट्री दोनों के लिए सक्षम होगा", इसलिए वास्तव में बिल्ड ट्री बायनेरिज़ में RPATH सेट होना चाहिए। @sanssecours क्या आप इसकी जांच कर सकते हैं? उदाहरण के लिए readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH ।

मुद्दा आरपीएटीएच के बारे में नहीं है, बल्कि लिनक्स पर DT_RPATH बनाम अन्य प्लेटफॉर्म पढ़ने पर dlopen बारे में है।

man dlopen ग्लिबक से:

• (केवल ईएलएफ) यदि कॉलिंग प्रोग्राम के लिए निष्पादन योग्य फ़ाइल में DT_RPATH टैग है, और इसमें DT_RUNPATH टैग नहीं है, तो DT_RPATH टैग में सूचीबद्ध निर्देशिकाओं की खोज की जाती है।
• यदि, उस समय जब प्रोग्राम शुरू किया गया था, पर्यावरण चर LD_LIBRARY_PATH को निर्देशिकाओं की एक कोलन-पृथक सूची रखने के लिए परिभाषित किया गया था, फिर इन्हें खोजा जाता है। (सुरक्षा उपाय के रूप में इस चर को सेट-यूज़र-आईडी और सेट-ग्रुप-आईडी प्रोग्राम के लिए अनदेखा किया जाता है।)
• (केवल ईएलएफ) यदि कॉलिंग प्रोग्राम के लिए निष्पादन योग्य फ़ाइल में DT_RUNPATH टैग है, तो उस टैग में सूचीबद्ध निर्देशिकाओं की खोज की जाती है।
• कैश फ़ाइल /etc/ld.so.cache (ldconfig(8) द्वारा अनुरक्षित) की जाँच की जाती है कि इसमें फ़ाइल नाम के लिए कोई प्रविष्टि है या नहीं।
• निर्देशिकाएं /lib और /usr/lib खोजी जाती हैं (उस क्रम में)।

OSX पर man dlopen :

जब पथ में स्लैश वर्ण नहीं होता है (अर्थात यह केवल एक पत्ती का नाम है), dlopen() निम्नलिखित को तब तक खोजता है जब तक कि उसे एक संगत Mach-O फ़ाइल न मिल जाए: $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, वर्तमान कार्यशील निर्देशिका, $DYLD_FALLBACK_LIBRARY_PATH।

dlopen को यहां पूर्ण पथ के साथ काम करना चाहिए, या इसे ऊपर वर्णित पथों में से एक में होना चाहिए

लेकिन हम पूर्ण पथ नहीं करते हैं। तो पता नहीं यह जानकारी कैसे मदद करती है

प्लगइन्स के लिए पूर्ण आरपीएटीएच या पूर्ण पथ? सीएमके का दावा है कि उसके पास बिल्ड-पेड़ आरपीएटीएच का समर्थन है, इसलिए यदि आवश्यक हो तो इसे पूर्ण आरपीएटीएच का उपयोग करना चाहिए।

प्लगइन्स के लिए पूर्ण पथ वही है जो कई लोग करते हैं और यह एक आसान बदलाव होगा, लेकिन मुझे नहीं लगता कि यह इन-बिल्ड टेस्ट मामलों के लिए कैसे मदद नहीं करेगा।

सबसे पहले यह दिलचस्प होगा कि यहां वास्तविक समस्या क्या है। क्या स्थापित संस्करण वास्तव में पूरी तरह से काम करता है? जैसे kdb run_all भी दिलचस्प होगा (जो मैंने पहले ही ऊपर लिखा था)।

dlopen मैनपेज से मेरा पेस्ट स्पष्ट रूप से बताता है कि समस्या क्या है।
विभिन्न प्लेटफार्मों पर dlopen(libelektra-resolver.so) का खोज पथ अलग है। Linux काम करता है क्योंकि dlopen libelektra-kdb.so के DT_RPATH का सम्मान करता है

ऐसा लगता है कि LD_LIBRARY_PATH को सेट करना वही है जो वाल्व भी कर रहा है।
https://github.com/ValveSoftware/steam-runtime/blob/master/runtime/run.sh

आपका मतलब समस्या यह है कि वे दस्तावेज नहीं लिखते हैं? @rpath का उल्लेख वहां भी नहीं किया गया है।

मुझे लगता है कि जब तक हम यह नहीं जानते कि BUILD_SHARED के साथ/स्थापित होने पर वास्तव में क्या काम करता है, हमें आगे अनुमान नहीं लगाना चाहिए।

@ मार्कस2330
संपादित करें: BUILD_STATIC और BUILD_FULL को अक्षम करना:
testkdb* परीक्षण ठीक चलता है।

दस्तावेज़ीकरण के बारे में, वे यहाँ @rpath का उल्लेख करते

एक संक्षिप्त उदाहरण द्वारा मेरे कथन की पुष्टि की:

• runtimelib ... एक पुस्तकालय जो कुछ यादृच्छिक कार्य प्रदान करता है। (इलेक्ट्रा-रिज़ॉल्वर की तरह)
• lib ...एक पुस्तकालय जो runtimelib को रनटाइम पर dlopen का उपयोग करके लोड करता है। इसमें DT_RPATH runtimelib की निर्देशिका में सेट है। (बाइंडिंग के kdb.so की तरह)
• runner ... एक निष्पादन योग्य जो lib रनटाइम पर dlopen (जैसे लुआ/पायथन) का उपयोग करके लोड करता है

देखें https://gist.github.com/manuelm/43a4fa9dd424b4dcf03bd1d773a0e122

यह परिदृश्य लिनक्स पर काम करता है, लेकिन फ्रीबीएसडी पर विफल रहता है।

मुझे पता है कि पुस्तकालय में सेट RPATH पोर्टेबल नहीं है (यह भी musl के लिए काम नहीं करता है)। लेकिन ऐसा लगता है कि मैक ओएस एक्स के लिए काम करना ( @mpranj ने यह भी बताया कि testkdb* परीक्षण ठीक काम करते हैं और @omnidan ने मैक ओएस एक्स के साथ kdb काम करने की सूचना दी)। इस प्रकार मैंने जांच करने के लिए कहा कि केवल पायथन/लुआ परीक्षण क्यों विफल हो जाते हैं।

Elektra को स्थापित करने का पोर्टेबल तरीका TARGET_PLUGIN_FOLDER सेट नहीं कर रहा है और परीक्षणों के लिए हम उपयोग कर सकते हैं (जैसा कि सुझाव दिया गया है) LD_LIBRARY_PATH । (हमें इसे केवल run_memcheck और run_all के भीतर सेट करने की आवश्यकता होगी)।

@mpranj ने यह भी बताया कि testkdb* परीक्षण ठीक काम करता है और @omnidan ने केडीबी मैक ओएस एक्स के साथ काम करने की सूचना दी

testkdb* और kdb ने DT_RPATH को स्वयं सेट किया है। पायथन और लुआ दुभाषिया नहीं है। यह मौलिक रूप से अलग है।

[...] और परीक्षणों के लिए हम उपयोग कर सकते हैं (जैसा कि सुझाव दिया गया है) LD_LIBRARY_PATH।

फिर कृपया इसे जोड़ें। धन्यवाद

हां, आप बिल्ड सिस्टम के लिए सही हैं: सीएमके प्रत्येक निष्पादन योग्य पर आरपीएटीएच सेट करता प्रतीत होता है, लेकिन स्पष्ट रूप से पायथन/लुआ के लिए नहीं।

हालाँकि, स्थापित होने पर, इसे सेट नहीं किया जाएगा। तो कृपया कोई पुष्टि करें कि kdb काम करता है ( TARGET_PLUGIN_FOLDER सेट के साथ)।

@sanssecours क्या आप BUILD_STATIC और BUILD_FULL को अक्षम कर सकते हैं और सभी ( testkdb ) परीक्षणों को फिर से चला सकते हैं?

ऐसा लगता है कि यह इतना नहीं बदलता है, सिवाय इसके कि ninja test कम परीक्षण चलाता है (114 के बजाय 54)। परीक्षण test_kdb.lua और testpy2_kdb.py अभी भी विफल हैं। अन्य सभी परीक्षण (प्रतीत होते हैं) काम करने के लिए।

https://cmake.org/Wiki/CMake_RPATH_handling कहता है ".. मैक ओएस एक्स पर RPATH। यह बिल्ड ट्री और इंस्टाल ट्री दोनों के लिए सक्षम होगा", इसलिए वास्तव में बिल्ड ट्री बायनेरिज़ में RPATH सेट होना चाहिए। उदाहरण के लिए readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH ।

मैंने कमांड का इस्तेमाल किया otool -l lib/libelektra-resolver.so — libelektra-core.so.0.8.16 मेरी मशीन पर मौजूद नहीं है। आउटपुट के अनुसार:

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

RPATH सेट है।

जैसे kdb run_all भी दिलचस्प होगा (जो मैंने पहले ही ऊपर लिखा था उसके आगे)।

मेरी मशीन पर ६५५ में से ५ परीक्षण विफल हो जाते हैं। परीक्षणों में से 4 ( testmod_crypto , testmod_iterate , testmod_semlock और testmod_template ) एक ही मूल त्रुटि के कारण विफल हो जाते हैं:

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

परीक्षण testmod_python2 निम्न त्रुटि आउटपुट दिखाता है:

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

नीचे testmod_lua का आउटपुट दिया गया है, जो किसी त्रुटि की रिपोर्ट नहीं करता है।

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

OS X पर dylibs बनाए जाते हैं, .so नहीं। वहाँ निश्चित रूप से एक libelektra-core.0.8.16.dylib या समान है।

वहाँ निश्चित रूप से एक libelektra-core.0.8.16.dylib या समान है।

तुम सही हो। ऐसा लगता है कि RPATH libelektra-core.0.8.16.dylib लिए सेट नहीं है, क्योंकि otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH कोई आउटपुट प्रदर्शित नहीं करता है।

grep आउटपुट छोटा न हो, या grep लोअरकेस rpath

grep आउटपुट छोटा न हो, या grep लोअरकेस rpath

क्या आपका मतलब है "आउटपुट grep मत करो, जो छोटा है, या grep लोअरकेस rpath"? अगर ऐसा है तो क्यों नहीं? मैंने अपने टर्मिनल एप्लिकेशन की अंतर्निहित खोज के माध्यम से RPATH के आउटपुट में otool -l lib/libelektra-core.0.8.16.dylib खोज की। यह LC_RPATH की कोई घटना नहीं दिखाता है।

अगर मैं rpath खोजता हूं, तो मुझे @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
...

जहां तक ​​​​मुझे पता है @rpath केवल एक प्लेसहोल्डर है (मानों में संग्रहीत) RPATH । मुझे नहीं लगता कि rpath की यह घटना हमें बताती है कि RPATH सेट है या नहीं।

सीएमके विकी के मुताबिक कमांड otool -l <file> | grep LC_RPATH -A2 कुछ फाइलों के आरपीएटीएच दिखाने का एक संभावित तरीका है। मुझे लगता है कि कम फैंसी संस्करण जो मैंने इस्तेमाल किया - otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH - कमोबेश ठीक भी होना चाहिए।

दोस्तों, आप इसे बिल्कुल क्यों चेक कर रहे हैं?

@sanssecours क्षमा करें, मैंने अपने फोन से संदेश जल्दी भेज दिया, इसलिए मैंने नहीं देखा कि इसका कोई मतलब नहीं है।

मैं otool -L का जिक्र कर रहा था जो निर्भरताओं को दिखाता है और केवल @rpath प्रदर्शित करता है। लेकिन हाँ आप सही कह रहे हैं otool -l सही आदेश है।

बीटीडब्ल्यू मुझे अपने सिस्टम में एक भी पुस्तकालय नहीं मिला है जो इलेक्ट्रा को छोड़कर आरपीएटीएच का उपयोग कर रहा है।

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

जैसा कि @manuelm कहता है, हालांकि, ये चेक व्यर्थ हो सकते हैं ...

मुझे नहीं लगता कि हम उपरोक्त सभी मुद्दों को पूरी तरह से समझते हैं, लेकिन मैं मानता हूं कि हम जिस तरह की रिमोट डिबगिंग कर रहे हैं वह कुशल नहीं है। किसी को जांच करनी चाहिए और दस्तावेज करना चाहिए कि गैर-ग्लिबैक सिस्टम का समर्थन करने का सबसे अच्छा तरीका क्या है। आइए बैठक में चर्चा करें कि कैसे आगे बढ़ना है।

@ मार्कस २३३० मैं इस मुद्दे को पूरी तरह से समझता हूं। परीक्षण शुरू होने से पहले LD_LIBRARY_PATH सेट करें और मैं वादा करता हूं कि समस्या दूर हो गई है।

अन्य सभी उल्लिखित मुद्दे लाल झुंड हैं या सिर्फ गलत हैं।

@manuelm मैं अच्छा बनना चाहता था और कहा "हम"। स्पष्ट रूप से LD_LIBRARY_PATH बिल्ड निर्देशिका में पुस्तकालयों को नहीं ढूंढने के मुद्दों को ठीक करेगा (जब तक कि इसे कहीं रीसेट नहीं किया जाता है, जो कम से कम पायथन/लुआ जीआई परीक्षणों के मामले में प्रतीत होता है)। लेकिन अगर आपका सिद्धांत सही है कि RPATH को बाइनरी में सेट किया जाना चाहिए, तो स्थापित संस्करण भी टूट जाएगा, जिसकी वर्तमान में पुष्टि नहीं की गई है। इसकी जांच होनी चाहिए।

मेरा सिद्धांत अब केवल एक सिद्धांत नहीं है, क्योंकि मैंने प्रमाण कर लिया है।

एक बार फिर: लिनक्स पर बाइंडिंग काम करती है क्योंकि लाइब्रेरी बाइंडिंग को लागू करती है (लुआ/पायथन के लिए kdb.so और ग्लिब के लिए libgelektra-4.0.so ) में DT_RPATH सेट _AND_ dlopen इसका सम्मान करता है।

इलेक्ट्रा को ग्लोबल सिस्टम लाइब्रेरी पथ में स्थापित करने के बाद निश्चित रूप से बाइंडिंग काम करेगी। मुझे बिल्कुल कोई कारण नहीं दिखता कि यह अचानक काम करना बंद कर दे।

बाइंडिंग के परीक्षण !=linux के लिए काम नहीं करते हैं। बस इतना ही।

पुनश्च: मुझे पता है कि जीआई बाइंडिंग परीक्षणों के लिए LD_LIBRARY_PATH की आवश्यकता होती है। इसलिए मैं चाहता था कि आप किसी प्रकार का बिल्ड सिस्टम मैक्रो जोड़ें जो जीआई मामले को एकीकृत/जोड़ता है।

ऐसा लगता है कि बाध्यकारी परीक्षण ही एकमात्र स्थान है जहां LD_LIBRARY_PATH की आवश्यकता है, इसलिए मैंने इसे वहीं जोड़ा।

@mpranj उम्मीद है कि हमें जल्द ही एक ट्रैविस मिलेगा जो पुष्टि कर सकता है कि यह काम करता है या नहीं?

@ मार्कस २३३० नहीं, यह काम नहीं करता है। (न तो ट्रैविस पर और न ही मेरी मशीन पर)

@mpranj परीक्षण के लिए धन्यवाद। क्या आपके पास ट्रैविस फ़ाइल किसी को परेशान किए बिना इसे फिर से जांचने के लिए तैयार है? दोनों परीक्षण मामले अभी भी विफल हो रहे हैं? क्या मैं LD_LIBRARY_PATH को कहीं भूल गया था या दृष्टिकोण बस काम नहीं कर रहा है?

@ मार्कस २३३० हाँ, मैं वर्तमान में ट्रैविस पर परीक्षण कर रहा हूँ, लेकिन यह मेरी मशीन के समान ही व्यवहार करता है। ऐसा लगता है कि da243f9e25d8fa14f8286c48b4338a73c1e7242d से कोई फर्क नहीं पड़ा।

आप इसे यहां देख सकते हैं: https://travis-ci.org/mpranj/libelektra
और बीटीडब्ल्यू ऐसा लगता है जैसे

हाँ, उसने ऐसा कहा। मुख्य रूप से मैक ओएस एक्स और अन्य को एक ट्रैविस फ़ाइल के साथ बनाने के लिए मैट्रिक्स सेटअप गायब था।

आपकी सभी मदद के लिए धन्यवाद, समस्या को अभी ठीक किया जाना चाहिए।