Iperf: مطلوب ldconfig في جعل التثبيت؟

لقد اختبرت هذا للتو على الكود من طرف الفرع الرئيسي iperf3 على CentOS 6. تم استدعاء ldconfig لي كجزء من "make install" (يبدو أن هذا جزء مما يتم بواسطة libtool --mode = install) ، وتمكن iperf3 من العثور على مكتبته المشتركة فور التثبيت ، ولا حاجة إلى ldconfig يدوي. أتساءل عما إذا كان هذا شيئًا خاصًا بتوزيع Linux؟

تقرير آخر عن هذه المشكلة على نظام أوبونتو آخر ، نفس الأعراض. كان هذا النظام هو: Ubuntu 12.04.3 LTS (GNU / Linux 3.8.0-31-generic i686).

أتساءل عما إذا كان الذهاب إلى libtool / autoconf / automake الأحدث سيساعد في هذه المشكلة؟

حسنًا ، لقد تمكنت من إعادة إنتاج هذا على Ubuntu VM (12.04 LTS ، والذي قمت بالطبع ببنائه في نفس اليوم الذي ظهر فيه 14.04 LTS). ما زلت تتأرجح قليلاً على Ubuntu ، لذلك لم تصل حقًا إلى هذا الحد مع حل بعد.

كان تشغيل ldconfig مطلوبًا أيضًا على Debian Wheezy (7.5) 64bit. في صحتك،

تحديث: تم نشر شخص ما (نسيت من كان) في أداة تعقب مشكلات رمز Google أنهم رأوا هذه المشكلة على Ubuntu Trusty (14.04 LTS). تمكنت أيضًا من إعادة إنتاج هذا (بعد الموضة) على CentOS 6.

يبدو أن المشكلة تكمن في أنه بعد تثبيت المكتبات المشتركة ، يتم تشغيل Makefile goop المُنشأ تلقائيًا ldconfig -n /usr/local/lib . يؤدي هذا إلى إعادة إنشاء بعض الارتباطات الرمزية للمكتبات المثبتة حديثًا. ومع ذلك ، وفقًا لـ ldconfig (8) ، يشير -n إلى -N ، مما يؤدي إلى عدم إعادة إنشاء ذاكرة التخزين المؤقت للمكتبة المشتركة ، وهي بالضبط المشكلة التي نراها. يؤدي تشغيل ldconfig بدون وسيطات إلى إعادة إنشاء ذاكرة التخزين المؤقت.

يبدو أن هذه مشكلة طويلة الأمد مع مزيج من autoake و libtool ... الكثير من التفاصيل المثيرة للاهتمام (على الرغم من أنها قديمة) هنا:

http://gnu-automake.7480.n7.nabble.com/quot-error- while-loading-shared-libraries-foo-so-0-cannot-open-shared-object-file-No-such-file- أو-di-td3970.html

أحد الاقتراحات هو إضافة شيء مثل هذا إلى src/Makefile.am :

install-exec-hook:
        ldconfig

يبدو أن هذا قد أصلح المشكلة ... تم اختباره باستخدام make install متبوعًا مباشرة باستدعاء iperf3 على CentOS 6 و Ubuntu 12.04 LTS.

لقد تسبب هذا في بعض المشكلات مع الأشخاص الذين يحاولون التثبيت كمستخدم غير جذر (يتم تثبيت حالات الاستخدام في تسلسل هرمي للدليل الخاص أو إنشاء RPM كمستخدم غير جذر). بشكل أساسي ، لا يريد ldconfig كما تم استدعاؤه أن يتم تشغيله على أنه ليس جذرًا لأنه يفتقر إلى أذونات الملفات الكافية.

ربما يجب تغيير استدعاء ldconfig للقيام بشيء مثل:

install-exec-hook:
        if [ "x`id -u $USER`" = "x0" ]; then ldconfig; fi

إعادة فتح هذه المشكلة لمحاولة أخرى.

هذا لا يعمل على نظام MacOS ، الذي لا يستخدم ldconfig ، وفي الواقع يتسبب في حدوث أخطاء على هذا النظام الأساسي.

استهداف هذا الخطأ 3.1. بطريقة أو بأخرى ، نحتاج إلى نوع من الدقة لهذا الأمر ، حتى لو كان مجرد وجود العنصر في قسم المشكلات المعروفة.

هذه بالفعل مشكلة تثبيت برنامج عامة. لن نقوم بحلها هنا ، بالنظر إلى الصعوبات في القيام بذلك عبر منصات متعددة. إغلاق دون إصلاح.

إذا كنت تريد التمسك بـ /usr/local/lib بدلاً من /usr/lib32 على توزيعة Ubuntu ، فما عليك سوى تشغيل ldconfig /usr/local/lib (يتطلب الجذر) في نهاية make install .

يرجى تطبيق هذا الحل السريع للسماح لمستخدمي Ubuntu بتثبيت iperf3.

انظر: http://stackoverflow.com/questions/4743233/is-usr-local-lib-searched-for-shared-libraries

شكرًا لتشغيل ldconfig بعد "make install" الذي حل المشكلة بالنسبة لي.

تشغيل Debian 7.8 64Bit (صرير). إذا كانت المشكلة كما هو موضح في العنوان ، فقم بتشغيل "sudo ldconfig" بعد التثبيت ، وتعمل بشكل جيد الآن. شكرا للمساعدة في هذا الموضوع.

كان لا بد من استخدام هذا على أحدث إصدار (3.1.3) مع ubuntu. إذا كان هذا مطلبًا ضروريًا لجميع إصدارات ubuntu ، أقترح أن يكون الأمر مفيدًا مما يجعله أكثر وضوحًا حتى لا يحتاج المستخدم إلى البحث في google / github لبدء

نفس الشيء هنا مع Ubuntu 16.04 (Xenial Xerus).
من الأفضل أن تقدم أوبونتو إشارات تحذيرية حول هذا الأمر ما لم يضيع شخص مثلي مرة أخرى ...

هل لدى أي شخص إصلاح للخطأ iperf3 على نظام التشغيل Mac OSX؟ باستخدام iperf3 3.2 ، باستخدام غلاف Python ، أرى أن libiperf.so.0 غير موجود.

@ jmack51 : في نظام التشغيل Mac OS ، لن تكون هناك مكتبة مشتركة *.so.0 ... يستخدم نظام التشغيل mac ملحق *.dynlib لمكتباته المشتركة. إذا كان "غلاف Python" يشير إلى iperf3-python ، فهذا مشروع منفصل وربما يتعين عليك تناول هذا الأمر معهم (لست متأكدًا مما إذا كان هناك خطأ هنا أم لا).

@ jmack51 : آه ، تجاهل ، أرى المكان الذي فتحت فيه بالفعل مشكلة مع thiezn / iperf3-python.

شكرًا بروس ، آسف على البريد العشوائي ، للسجل الذي انتهى في https://github.com/thiezn/iperf3-python/issues/23

سأعيد فتح هذه المشكلة ، على الرغم من أنه ليس لدي فكرة جيدة حول كيفية إصلاحها. هناك حالات استخدام مختلفة:

• الأنظمة التي تحتاج إلى ldconfig ليتم تشغيلها.
• الأنظمة التي لا تحتاج إلى ldconfig. ،
• الأنظمة التي تحتاج إلى ldconfig مع بعض المعلمات (مثل اسم المسار).
• الأنظمة التي لا تحتوي على ldconfig (مثل macOS).
• عبر التجميع.

أفكر في شيء مثل ما اقترحته في 10 يونيو 2014 ، ولكني أتجاهل شروط الخطأ. سيكون رائعًا إذا كان بإمكان شخص ما التعليق على حالة التجميع المتقاطع ... إذا كنت تقوم بالتجميع المتقاطع لبعض الأنظمة الأساسية الأخرى ، فافعل ذلك كامل make install لعرض الملفات في مكان ما أو make compile ؟

لقد واجهت هذه المشكلة ، وكنت آمل أن تتمكن من مساعدتي في اكتشاف حل لها.

أحاول تشغيل iperf3 على armv5 QNAP NAS.

تمكنت من تثبيته. لكن عند تشغيله ، أحصل على هذه المشكلة: iperf3: error while loading shared libraries: libiperf.so.0: cannot open shared object file: No such file or directory

ldconfig (w / or w / o sudo) لم يصلحه للأسف.

[/] # find . -name libiperf.so.*
./mnt/ext/usr/local/lib/libiperf.so.0
./mnt/ext/usr/local/lib/libiperf.so.0.0.0
./share/HDA_DATA/homes/admin/downloads/iperf-3.5/src/.libs/libiperf.so.0.0.0
./share/HDA_DATA/homes/admin/downloads/iperf-3.5/src/.libs/libiperf.so.0

ls -la من / يعطي
lrwxrwxrwx 1 admin administ 12 Mar 30 10:18 usr -> /mnt/ext/usr/

[/usr/local/lib] # ls -la libiperf.s*
lrwxrwxrwx    1 admin    administ        17 Mar 30 21:32 libiperf.so -> libiperf.so.0.0.0*
lrwxrwxrwx    1 admin    administ        17 Mar 30 21:32 libiperf.so.0 -> libiperf.so.0.0.0*
-rwxr-xr-x    1 admin    administ    380032 Mar 30 21:32 libiperf.so.0.0.0*

لقد حاولت إضافة /mnt/ext/usr/local/lib إلى /etc/ld.so.conf ثم _ ثم تشغيل ldconfig بدون حظ.

هذا ما كان يبدو عليه من قبل (ومنذ ذلك الحين قمت بإزالته مرة أخرى):

[/mnt/ext/usr/local/lib] # cat /etc/ld.so.conf 
/lib
/usr/lib
/usr/local/lib

ماذا أفعل / أحاول؟

BeyondEvil هل حاولت استخدام متغير بيئي LD_LIBRARY_PATH؟

ralcini لا لم أفعل ، (على ما أظن). سأجربه. 👍

بالنسبة لاستعلام التجميع المتقاطع في https://github.com/esnet/iperf/issues/153#issuecomment -365012358 ، استخدمت make install نطاق واسع. أعتقد أن معظم أنظمة البناء تفعل ذلك أيضًا - خاصةً إذا كان المشروع آليًا.

أود أن أقترح كطعنة أولى في هذا الأمر ، يمكن لعملية إنشاء iperf أن تضع رسائل على وحدة التحكم تشير إلى الأمر الذي يجب تشغيله. بمجرد أن نحصل على ذلك ، توقف عن فعل ذلك بالفعل.

هل هناك قائمة بأنظمة (* nix) تحتاج إلى تشغيل ldconfig وأيها لا يحتاج؟ يقع macOS و Windows في قائمة عدم طلب تشغيل ldconfig بعد التثبيت.

جانبا ، لدي فضول لمعرفة أي الأنظمة لا تحتاج إلى ldconfig لتشغيلها وكيف يتم إدارتها.

إغلاق. هذه ليست مشكلة iperf3 فقط ، ويبدو أنه لا يوجد أي شخص آخر لديه حل جيد لها أيضًا. (أود أن أفترض أن مزيجًا من automake و libtool يجب أن يتعامل مع هذه المشكلة.)

نعم ، يبدو أنها مشكلة libtool. آخر مرة قمت فيها بمطاردة هذا ، وجدت ما يلي في متتبع أخطاء GNU:

https://debbugs.gnu.org/cgi/bugreport.cgi؟bug=30402

في عام 1997 ، التزم 7f9b4e50 بإصدار libtool 0.6b ، طريقة التشغيل
تم تغيير ldconfig من التشغيل بدون "-n" إلى التشغيل مع "-n".

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