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٪ من الحوادث المرتبطة بالتطهير كانت مرتبطة بأعطال بيئة البناء. لذا حاول أولاً إعادة إنشاء (!) + إعادة تجميع روابط swig.

قد تكون هذه المشكلة متعلقة بـ ad537b3 (على الأقل في Linux kdb * lua | python كان يتعطل ، لكن الإصلاح لنظام Linux جزء من ad537b3). بدون ناتج الاختبار لا يمكن للمرء أن يخبرنا حقًا.

يمكنك استخدام make run_all الذي يمنع إخراج حالات الاختبار الناجحة ولكنه يعرض مخرجات الحالات الفاشلة.

sanssecours هل من تحديث لهذا؟

قد تكون هذه المشكلة متعلقة بـ ad537b3 (على الأقل في Linux kdb * lua | python كان يتعطل ، لكن الإصلاح لنظام Linux جزء من ad537b3). بدون ناتج الاختبار لا يمكن للمرء أن يخبرنا حقًا.

sanssecours هل من تحديث لهذا؟

اسف على الجواب المتاخر. اعتقدت أنني كتبت بالفعل تعليقًا يحتوي على معلومات موسعة حول هذه المشكلة. اسمحوا لي أن أبدأ بالقول أن testpy2_kdb.py فشل أيضًا على جهازي. لذلك قد تكون مشكلة في الإعداد المحدد الخاص بي. لقد قمت بتثبيت SWIG عبر Homebrew وأستخدم حاليًا الأمر cmake لإنشاء ملفات الإنشاء لـ Elektra:

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

يبدو أن Lua غير قادر على العثور على libelektra-resolver.so ، الموجود في build/lib و /usr/local/lib/elektra على جهازي. هل أحتاج إلى تعيين مسار مكتبة حتى يعمل هذا؟ بالمناسبة ، يبدو أن testpy2_kdb.py فشل أيضًا بسبب نفس المشكلة بالضبط.

الروابط لا تحمل أي مكتبة elektra في وقت التشغيل. هم مجرد ارتباطات. يمكنك رؤية هذا من خلال النظر إلى موقع الخطأ الدقيق ، وهو ../src/libs/loader/dl.c:82 .

لذلك فهذه إما مشكلة في بيئتك ، أو مشكلة عامة في elektra على OSX أو مشكلة في نظام البناء على OSX. أظن في السابق. بينغ @ markus2330

dlopen(libelektra-resolver.so, 2): image not found لا علاقة له بـ lua.

يجب أن يكون libelektra-resolver.so رابطًا رمزيًا لوحدة الحل التي حددتها باستخدام KDB_DEFAULT_RESOLVER ، فربما تعطل الإعداد / التثبيت؟ هل يمكنك التحقق من صحة الروابط الرمزية؟

الغريب هو: يتم استخدام libelektra-resolver.so في كل حالة اختبار متعلقة بـ kdb ، فلماذا _لا يعمل فقط في حالة الاختبار هذه؟ ربما تستخدم حالة الاختبار هذه (وحالة Python) المكتبة المثبتة وليس المكتبة في دليل الإنشاء. يمكنك التحقق من strace الذي libelektra-resolver.so ويحاول حالة اختبار لتحميل؟

image not found عام تمامًا ، فربما لم يتم العثور على صورة العمارة الخاصة بك داخل المكتبة؟ هل تستخدم ثنائيات الدهون ؟

يجب أن يكون libelektra-resolver.so رابطًا رمزيًا لوحدة الحل التي حددتها باستخدام KDB_DEFAULT_RESOLVER ، فربما تعطل الإعداد / التثبيت؟

هل هناك طريقة سهلة للتحقق مما إذا كان تثبيت Elektra المحلي معطلاً؟ يبدو أن الأمر kdb يعمل.

هل يمكنك التحقق من صحة الروابط الرمزية؟

كل من الأسماء المستعارة libelektra-resolver.so مرتبطة بملف libelektra-resolver_fm_hpu_b.so موجود في نفس الدليل مثل الأسماء المستعارة. لذلك يبدو أنهم على صواب.

يمكنك التحقق من strace الذي libelektra-resolver.so ويحاول حالة اختبار لتحميل؟

حاولت sudo dtruss ctest -V -R test_kdb.lua . هنا هو الإخراج:
test_kdb.lua - إخراج dtruss.txt . يبدو أن الاختبار يستخدم إصدار Elektra في دليل الإنشاء. قمت بإلغاء تثبيت Elektra عبر sudo ninja uninstall . ثم أجريت الاختبار مرة أخرى. الإخراج لا يزال هو نفسه.

هل تستخدم ثنائيات الدهون؟

ليس على حد علمي.

هل تستخدم OSX El Capitan؟ قد تكون مشكلة غريبة في حماية تكامل النظام .

من الغريب أن kdb يعمل بالرغم من ذلك.

إذا كان الأمر يتعلق بحماية تكامل النظام بسبب تثبيت python / lua ، فقد يكون ذلك منطقيًا.

هل تستخدم OSX El Capitan؟ قد تكون مشكلة غريبة في حماية تكامل النظام.

نعم ، أستخدم OS X 10.11.4. لقد عطلت SIP مؤقتًا وقمت بإجراء الاختبار مرة أخرى. لا تزال نفس المشكلة. على الرغم من أنني بعد تعطيل SIP ، واجهت اختبارًا جديدًا فشل: testscr_check_kdb_internal_suite . والآن لا يعمل testscr_check_merge أيضًا بعد الآن 😢.

عدت إلى 0.8.16 ، وقمت بتنظيف دليل الإنشاء وقمت بتشغيل ninja test مرة أخرى. لا يزال كل من testscr_check_kdb_internal_suite و testscr_check_merge يفشل ، على الرغم من أنني تذكرت ، أن ما لا يقل عن testscr_check_kdb_internal_suite يعمل عند إصدار Elektra 0.8.16. فيما يلي ناتج الاختبار الإضافي الذي فشل الآن أيضًا:
الاختباراتcr_check_kdb_internal_suite.txt
testcr_check_merge.txt

لقد غيرت العنوان وأزلت نفسي. ليس لدي وصول مباشر إلى جهاز OSX وأفتقر إلى المعرفة المتعمقة. بدون آلة تتجول فيها ، لا يمكنني معرفة أي شيء من إخراج النص.

هل ألقيت نظرة أيضًا على التلميحات الأخرى للروابط؟ على سبيل المثال إعادة تثبيت python / lua؟

@ petermax2mpranj هل يمكن استنساخ هذه القضايا؟

هل ألقيت نظرة أيضًا على التلميحات الأخرى للروابط؟ على سبيل المثال إعادة تثبيت python / lua؟

آسف ليس حقا. تثبيت Python 2 هو التثبيت الذي يأتي مع النظام. لإعادة تثبيته ، سأضطر إلى إعادة تثبيت نظام التشغيل بالكامل.

لقد قمت بتثبيت Lua فقط لاختبار المكون الإضافي Lua Elektra. لذلك لا أعتقد أن إعادة التثبيت منطقية. ومع ذلك ، نظرًا لأن الأمر لا يستغرق سوى ثوانٍ ، فقد نفذت 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 على OS X عمليات البحث $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH ، أعتقد بهذا الترتيب.

يعمل PR # 710 على إصلاحه ، لكنني لست متأكدًا مما إذا كان الإصلاح نظيفًا جدًا.

لا ، الإصلاح بالتأكيد ليس نظيفًا.

بقدر ما أتذكر ، تعتمد اختباراتنا على تعيين DT_RPATH في libelektra-kdb.so . إذا لم يكن هذا متاحًا في OSX ، فيجب علينا تحديد ذلك في بعض بيئة البناء العالمية.

تحرير: ولكن شكرا لاكتشاف ذلك!

RPATH لجميع المكتبات الأساسية ، ولكن ربما يكفي libelektra-core : في هذا المكان يحدث dlopen .

هل يعني image not found ببساطة عدم وجود مكتبة؟ إذا كان الأمر كذلك ، فهل لديك أي فكرة عن سبب عمل RPATH للجميع باستثناء اختبارات lua و python؟

لمعلوماتك فقط: تدعم Elektra أيضًا الأنظمة التي لا تحتوي على RPATH (على سبيل المثال openwrt مع musl مثل libc) عن طريق تعيين TARGET_PLUGIN_FOLDER على سلسلة فارغة.

يبدو أن أشياء مماثلة تحدث على FreeBSD بالمناسبة.

 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:

لم أتمكن من التحقق من lua على FreeBSD حتى الآن.

من الجيد معرفة 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 تعمل (مجرد فحص سريع باستخدام ls).

وإلا فإن الكثير من الأشياء تفشل ولكنني لن أتمكن من التحقق / الإبلاغ عن كل شيء اليوم. لكن من المؤكد أنني سأبلغ عن كل شيء عندما أتمكن من اختباره بشكل صحيح.

أعتقد أن اختبارات kdb تعمل لأنها مرتبطة بشكل ثابت ، أليس كذلك؟
إذا قمت بتعطيل BUILD_STATIC ، فلن تعمل الاختبارات أيضًا.

@ markus2330 لا أعتقد أنه يمكننا تجنب تعيين LD_LIBRARY_PATH على بعض الأنظمة الأساسية. كيف يعمل TARGET_PLUGIN_FOLDER ؟ أو بشكل أكثر تحديدًا كيف يحل هذا البحث الديناميكي في المكتبة؟

شكرًا هذه فكرة جيدة: sanssecours هل يمكنك تعطيل BUILD_STATIC و BUILD_FULL وإعادة تشغيل جميع اختبارات ( testkdb )؟

إذا كان TARGET_PLUGIN_FOLDER فارغًا ، يتم تثبيت المكونات الإضافية حيث توجد المكتبات ولا يلزم وجود RPATH أو LD_LIBRARY_PATH . ولكنه لن يساعد إلا عند استخدام Elektra المثبت (والذي قد يكون هو الحال بالنسبة لاختبارات python / lua ).

https://cmake.org/Wiki/CMake_RPATH_handling يقول ".. RPATH على نظام التشغيل Mac OS X. سيتم تمكينه لكل من شجرة البناء وشجرة التثبيت" ، لذلك في الواقع أيضًا يجب أن تحتوي ثنائيات شجرة البناء على مجموعة RPATH. sanssecours هل يمكنك التحقق من هذا؟ على سبيل المثال ، باستخدام readelf -a lib/libelektra-core.so.0.8.16 | grep RPATH .

لا تتعلق المشكلة بـ RPATH نفسها ، ولكن حول dlopen عند قراءة linux DT_RPATH مقابل الأنظمة الأساسية الأخرى.

man dlopen من glibc:

• (ELF فقط) إذا كان الملف القابل للتنفيذ لبرنامج الاستدعاء يحتوي على علامة DT_RPATH ، ولا يحتوي على علامة DT_RUNPATH ، فسيتم البحث في الدلائل المدرجة في علامة DT_RPATH.
• إذا تم تعريف متغير البيئة LD_LIBRARY_PATH في وقت بدء البرنامج بحيث يحتوي على قائمة من الدلائل مفصولة بنقطتين ، فسيتم البحث عنها. (كإجراء أمني ، يتم تجاهل هذا المتغير لبرامج معرّف المستخدم والمجموعة المحددة.)
• (ELF فقط) إذا كان الملف التنفيذي لبرنامج الاستدعاء يحتوي على علامة DT_RUNPATH ، فسيتم البحث في الدلائل المدرجة في تلك العلامة.
• يتم فحص ملف ذاكرة التخزين المؤقت /etc/ld.so.cache (الذي يحتفظ به ldconfig (8)) لمعرفة ما إذا كان يحتوي على إدخال لاسم الملف.
• يتم البحث في الدلائل / lib و / usr / lib (بهذا الترتيب).

man dlopen على OSX:

عندما لا يحتوي المسار على حرف مائل (أي أنه مجرد اسم طرفية) ، يبحث dlopen () عما يلي حتى يعثر على ملف Mach-O متوافق: $ LD_LIBRARY_PATH ، $ DYLD_LIBRARY_PATH ، دليل العمل الحالي ، $ DYLD_FALLBACK_LIBRARY_PATH.

يجب أن يعمل dlopen مع المسارات المطلقة هنا ، أو يجب أن يكون في أحد المسارات المذكورة أعلاه

لكننا لا نقوم بمسارات مطلقة. لذلك لا توجد فكرة كيف تساعد هذه المعلومات

RPATH المطلق أو المسارات المطلقة للمكونات الإضافية؟ تدعي CMake أن لديها دعمًا لـ build-tree RPATH ، لذلك يجب أن تستخدم RPATH مطلقًا إذا لزم الأمر.

المسارات المطلقة للمكونات الإضافية هي ما يفعله الكثيرون وسيكون تغييرًا سهلاً ، لكنني لا أرى كيف لن يساعد ذلك في حالات الاختبار المضمنة.

أولاً سيكون من المثير للاهتمام ما هي المشكلة الفعلية هنا. هل النسخة المثبتة تعمل بشكل كامل؟ على سبيل المثال ، سيكون kdb run_all مثيرًا للاهتمام أيضًا (بجانب ما كتبته أعلاه بالفعل).

يوضح اللصق الخاص بي من dlopen manpages بوضوح ما تدور حوله المشكلة.
يختلف مسار البحث عن dlopen (libelektra-resolver.so) على منصات مختلفة. يعمل Linux لأن dlopen يكرم DT_RPATH من libelektra-kdb.so

يبدو أن تعيين LD_LIBRARY_PATH هو ما يفعله الصمام أيضًا.
https://github.com/ValveSoftware/steam-runtime/blob/master/runtime/run.sh

تقصد المشكلة هي أنهم لا يكتبون الوثائق؟ @rpath هناك.

أعتقد أنه حتى لا نعرف ما الذي يعمل فعليًا عند التثبيت / مع BUILD_SHARED ، لا ينبغي لنا التكهن أكثر.

يارب احفظها
تحرير: تعطيل BUILD_STATIC و BUILD_FULL:
تعمل اختبارات testkdb * بشكل جيد.

حول التوثيق ، يذكرون @rpath هنا .

لقد تحققت للتو من بياني من خلال مثال قصير:

• runtimelib ... مكتبة تقدم بعض الوظائف العشوائية. (مثل محلل اليكترا)
• lib ... مكتبة يتم تحميلها runtimelib في وقت التشغيل باستخدام dlopen . لقد تم تعيين DT_RPATH إلى الدليل runtimelib . (مثل kdb.so من الارتباطات)
• runner ... ملف تنفيذي يحمل lib في وقت التشغيل باستخدام dlopen (مثل lua / python)

انظر https://gist.github.com/manuelm/43a4fa9dd424b4dcf03bd1d773a0e122

يعمل هذا السيناريو على نظام Linux ، لكنه فشل في FreeBSD.

أعلم أن مجموعة RPATH في مكتبة ليست محمولة (كما أنها لا تعمل مع musl). ولكن يبدو أنه يعمل مع نظام التشغيل Mac OS X (ذكرت mpranj أيضًا أن اختبارات testkdb * تعمل بشكل جيد وأن omnidan أفادت أن kdb يعمل مع Mac OS X). لذلك طلبت التحقق من سبب فشل اختبارات python / lua فقط.

الطريقة المحمولة لتثبيت Elektra لا تحدد TARGET_PLUGIN_FOLDER وبالنسبة للاختبارات يمكننا استخدام (كما هو مقترح) LD_LIBRARY_PATH . (سنحتاج فقط إلى ضبطه داخل run_memcheck و run_all).

ذكرت mpranj أيضًا أن اختبارات testkdb * تعمل بشكل جيد وأن omnidan ذكرت أن kdb يعمل مع نظام التشغيل Mac OS X

testkdb* و kdb قاما DT_RPATH بتعيينهما بأنفسهما. مترجم بايثون ولوا لم يفعلوا ذلك. هذا يختلف اختلافًا جوهريًا.

[...] وبالنسبة للاختبارات يمكننا استخدام (كما هو مقترح) LD_LIBRARY_PATH.

ثم الرجاء إضافته. شكرا

نعم ، أنت على حق في نظام البناء: يبدو أن CMake تقوم بتعيين RPATH على كل ملف قابل للتنفيذ ، ولكن من الواضح أنه ليس من أجل python / lua.

ومع ذلك ، عند تثبيته ، لن يتم تعيينه. لذا يرجى تأكيد شخص ما إذا كان kdb يعمل (مع TARGET_PLUGIN_FOLDER مجموعة).

sanssecours هل يمكنك تعطيل BUILD_STATIC و BUILD_FULL وإعادة تشغيل جميع الاختبارات ( testkdb )؟

يبدو أن هذا لا يتغير كثيرًا ، باستثناء أن ninja test اختبارات أقل (54 بدلاً من 114). لا تزال الاختبارات test_kdb.lua و testpy2_kdb.py تفشل. (يبدو) أن جميع الاختبارات الأخرى تعمل.

https://cmake.org/Wiki/CMake_RPATH_handling يقول ".. RPATH على نظام التشغيل Mac OS X. سيتم تمكينه لكل من شجرة البناء وشجرة التثبيت" ، لذلك في الواقع أيضًا يجب أن تحتوي ثنائيات شجرة البناء على مجموعة 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 سيكون ممتعًا أيضًا (بجانب ما كتبته أعلاه بالفعل).

على جهازي ، تفشل 5 من أصل 655 اختبارًا. 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 ، وليس. هناك بالتأكيد 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 قصيرًا أو rpath صغيرًا

لا يكون إخراج grep قصيرًا أو rpath صغيرًا

هل تقصد "لا إخراج grep ، هذا قصير ، أو grep صغير rpath"؟ إذا كان الأمر كذلك ، فلماذا لا؟ لقد بحثت أيضًا عن RPATH في ناتج otool -l lib/libelektra-core.0.8.16.dylib عبر البحث المدمج في تطبيق Terminal الخاص بي. هذا أيضًا لا يظهر أي تكرارات لـ 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 أم لا.

وفقًا لـ CMake wiki ، فإن الأمر otool -l <file> | grep LC_RPATH -A2 هو إحدى الطرق الممكنة لإظهار RPATHs لبعض الملفات. أعتقد أن النسخة الأقل فخامة التي استخدمتها - otool -l lib/libelektra-core.0.8.16.dylib | grep RPATH - يجب أن تكون جيدة أكثر أو أقل أيضًا.

يا رفاق ، لماذا تتحققون من هذا على الإطلاق؟

sanssecours آسف ، لقد أرسلت الرسالة بسرعة من هاتفي ، لذلك لم أر أنها لا معنى لها.

كنت أشير إلى otool -L الذي يعرض التبعيات ويعرض فقط @rpath . لكن نعم ، أنت محق ، otool -l هو الأمر الصحيح.

راجع للشغل لم أجد مكتبة واحدة في نظامي تستخدم RPATH ، باستثناء elektra.

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

كما يقول manuelm ، قد تكون هذه الشيكات عديمة الجدوى إلى حد ما ...

لا أعتقد أننا نفهم تمامًا جميع المشكلات المذكورة أعلاه ، لكنني أوافق على أن نوع التصحيح عن بُعد الذي نقوم به ليس فعالاً. يجب على شخص ما التحقيق وتوثيق ما هو أفضل طريقة لدعم الأنظمة غير glibc. دعونا نناقش في الاجتماع كيفية المضي قدما.

@ markus2330 أفهم المشكلة تمامًا. اضبط LD_LIBRARY_PATH قبل بدء الاختبارات وأعدك بأن المشكلة قد ولت.

جميع القضايا الأخرى المذكورة هي رنجة حمراء أو خاطئة فقط.

manuelm أردت أن أكون لطيفًا وقلت "نحن". من الواضح أن LD_LIBRARY_PATH سيصلح مشكلات عدم العثور على المكتبات في دليل الإنشاء (ما لم تتم إعادة تعيينها في مكان ما ، ويبدو أن هذا هو الحال على الأقل بالنسبة لاختبارات python / lua GI). ولكن إذا كانت نظريتك صحيحة وهي أنه يجب تعيين RPATH في النظام الثنائي ، فسيتم أيضًا كسر الإصدار المثبت ، وهو ما لم يتم تأكيده بالفعل حاليًا. يجب التحقيق في هذا.

لم تعد نظريتي مجرد نظرية ، لأنني قدمت الدليل.

مرة أخرى: في نظام التشغيل Linux ، تعمل الارتباطات لأن المكتبة التي تنفذ الارتباطات ( kdb.so لـ lua / python و libgelektra-4.0.so لـ glib) لديها DT_RPATH set _AND_ dlopen يكرم هذا.

بالطبع ستعمل الارتباطات بعد تثبيت elektra في مسارات مكتبة النظام العالمي. لا أرى أي سبب على الإطلاق يجعل هذا يتوقف فجأة عن العمل.

لا تعمل اختبارات الارتباطات من أجل! = لينكس. هذا كل شئ.

ملاحظة: أعرف أن اختبارات ارتباطات الجهاز الهضمي تتطلب LD_LIBRARY_PATH. لهذا السبب أردت منك إضافة نوع من ماكرو نظام البناء الذي يدمج / يلحق حالة الجهاز الهضمي.

يبدو أن اختبارات الربط هي المكان الوحيد الذي يلزم فيه LD_LIBRARY_PATH ، لذلك أضفته هناك.

mpranj نأمل أن نحصل قريبًا على ترافيس يمكنه تأكيد ما إذا كان يعمل؟

@ markus2330 لا لا يعمل. (ليس على ترافيس ولا على جهازي)

mpranj شكرا للاختبار. هل لديك ملف ترافيس جاهز لاختباره مرة أخرى دون إزعاج شخص ما؟ كلتا حالات الاختبار ما زالت تفشل؟ هل نسيت LD_LIBRARY_PATH في مكان ما أم أن الأسلوب ببساطة لا يعمل؟

@ markus2330 نعم ، أقوم حاليًا باختبار ترافيس ، لكن في الغالب له نفس السلوك الموجود على جهازي. يبدو أن da243f9e25d8fa14f8286c48b4338a73c1e7242d لم يحدث فرقًا.

يمكنك رؤيته هنا: https://travis-ci.org/mpranj/libelektra
وبالمناسبة ، يبدو أن إنجازه إلى حد كبير باستخدام نظام travis + OS X. فشلت الاختبارات ولكن تم إعداد travis تقريبًا بالكامل على ما أعتقد.

نعم ، قال ذلك. بشكل أساسي ، كان إعداد المصفوفة لبناء نظام التشغيل Mac OS X والآخرين مع ملف travis واحد مفقودًا.

نشكرك على كل ما تبذلونه من المساعدة ، يجب حل المشكلة الآن.