Iperf: ldconfig dibutuhkan dalam make install?

Saya baru saja menguji ini pada kode dari ujung cabang master iperf3 di CentOS 6. ldconfig dipanggil untuk saya sebagai bagian dari "make install" (ini tampaknya menjadi bagian dari apa yang dilakukan oleh libtool --mode = install), dan iperf3 dapat menemukan pustaka bersama segera setelah instalasi, tidak diperlukan ldconfig manual. Saya ingin tahu apakah ini adalah sesuatu yang khusus untuk distribusi Linux?

Satu laporan lain dari masalah ini di sistem Ubuntu lain, gejala yang sama. Sistem ini adalah: Ubuntu 12.04.3 LTS (GNU / Linux 3.8.0-31-generic i686).

Saya ingin tahu apakah pergi ke libtool / autoconf / automake yang lebih baru akan membantu masalah ini?

OK saya dapat mereproduksi ini pada Ubuntu VM (12,04 LTS, yang tentu saja saya bangun pada hari yang sama ketika 14,04 LTS keluar). Masih sedikit gagal di Ubuntu, jadi belum benar-benar mencapai solusi sejauh itu.

Menjalankan ldconfig juga diperlukan di Debian Wheezy (7.5) 64bit. Bersulang,

Pembaruan: Seseorang (saya lupa siapa itu) memposting ke pelacak masalah Google Code bahwa mereka melihat masalah ini di Ubuntu Trusty (14.04 LTS). Saya juga bisa mereproduksi ini (setelah mode) di CentOS 6.

Masalahnya tampaknya setelah menginstal pustaka bersama, goop Makefile yang dibuat secara otomatis menjalankan ldconfig -n /usr/local/lib . Ini membangun kembali beberapa symlink untuk perpustakaan yang baru diinstal. Namun, menurut ldconfig (8), -n menyiratkan -N , yang menyebabkan cache perpustakaan bersama tidak dapat dibangun kembali, yang merupakan masalah yang sedang kita lihat. Menjalankan ldconfig tanpa argumen akan membangun kembali cache.

Ini tampaknya menjadi masalah lama dengan beberapa kombinasi automake dan libtool ... banyak detail menarik (meskipun lama) di sini:

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

Satu saran adalah menambahkan sesuatu seperti ini ke src/Makefile.am :

install-exec-hook:
        ldconfig

Ini tampaknya telah memperbaiki masalah ... diuji dengan make install segera diikuti oleh pemanggilan iperf3 di CentOS 6 dan Ubuntu 12.04 LTS.

Hal ini menyebabkan beberapa masalah dengan orang yang mencoba menginstal sebagai pengguna non-root (kasus penggunaan menginstal ke hierarki direktori pribadi atau membangun RPM sebagai pengguna non-root). Pada dasarnya ldconfig sebagai dipanggil tidak ingin dijalankan sebagai non-root karena tidak memiliki izin file yang memadai.

Mungkin pemanggilan ldconfig harus diubah untuk melakukan sesuatu seperti:

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

Membuka kembali masalah ini untuk mencoba lagi.

Ini tidak berfungsi di MacOS, yang tidak menggunakan ldconfig, dan faktanya menyebabkan kesalahan pada platform itu.

Menargetkan bug ini untuk 3.1. Dengan satu atau lain cara kita perlu memiliki semacam resolusi untuk ini, meskipun itu hanya memiliki item di bagian masalah yang diketahui.

Ini benar-benar masalah penginstalan perangkat lunak umum. Kami tidak akan menyelesaikannya di sini, mengingat kesulitan dalam melakukan ini di berbagai platform. Menutup tanpa perbaikan.

Jika Anda ingin tetap menggunakan /usr/local/lib daripada /usr/lib32 di distro Ubuntu, jalankan saja ldconfig /usr/local/lib (membutuhkan root) di akhir make install .

Harap terapkan solusi cepat ini untuk mengizinkan pengguna Ubuntu menginstal iperf3.

Lihat: http://stackoverflow.com/questions/4743233/is-usr-local-lib-searched-for-shared-libraries

Terima kasih menjalankan ldconfig setelah "make install" memecahkan masalah saya.

Menjalankan Debian 7.8 64Bit (wheezy). Jika masalah seperti yang ditentukan dalam judul, jalankan 'sudo ldconfig' post make install, berfungsi dengan baik sekarang. Terima kasih atas bantuannya di utas ini.

Harus menggunakan ini pada versi terbaru (3.1.3) dengan ubuntu. Jika ini menjadi persyaratan yang diperlukan untuk semua versi ubuntu saya sarankan itu bermanfaat membuatnya sedikit lebih jelas sehingga pengguna tidak perlu mencari google / github untuk memulai

Sama di sini dengan Ubuntu 16.04 (Xenial Xerus).
ubuntu lebih baik membuat tanda peringatan tentang ini kecuali seseorang seperti saya tersesat lagi ....

Apakah ada yang punya perbaikan untuk kesalahan iperf3 di Mac OSX? Dengan iperf3 3.2, menggunakan pembungkus Python, saya melihat libiperf.so.0 tidak ditemukan.

@ jmack51 : Di mac OS, tidak akan ada *.so.0 pustaka bersama ... mac OS menggunakan ekstensi *.dynlib untuk pustaka bersama. Jika "pembungkus Python" mengacu pada iperf3-python, itu adalah proyek terpisah dan Anda mungkin harus mengambilnya bersama mereka (saya tidak yakin apakah ada bug di sini atau tidak).

@ jmack51 : Ah, abaikan, saya melihat di mana Anda telah membuka masalah dengan thiezn / iperf3-python.

Terima kasih Bruce, maaf atas spamnya, untuk catatan yang sudah berakhir di https://github.com/thiezn/iperf3-python/issues/23

Saya akan membuka kembali masalah ini, meskipun saya tidak memiliki ide bagus tentang cara memperbaikinya. Ada berbagai kasus penggunaan:

• Sistem yang membutuhkan ldconfig untuk dijalankan.
• Sistem yang tidak membutuhkan ldconfig.,
• Sistem yang membutuhkan ldconfig dengan beberapa parameter (misalnya nama path).
• Sistem tanpa ldconfig (misalnya macOS).
• Kompilasi silang.

Saya memikirkan sesuatu seperti yang saya usulkan pada 10 Juni 2014, tetapi mengabaikan kondisi kesalahan. Akan sangat bagus jika seseorang dapat mengomentari kasus kompilasi silang ... jika Anda melakukan kompilasi silang untuk beberapa platform lain apakah Anda melakukan make install untuk mementaskan file di suatu tempat atau hanya make compile ?

Saya mengalami masalah ini, dan berharap Anda dapat membantu saya mencari solusinya.

Saya mencoba menjalankan iperf3 di armv5 QNAP NAS saya.

Saya berhasil menginstalnya. Tetapi menjalankannya, saya mendapatkan masalah ini: iperf3: error while loading shared libraries: libiperf.so.0: cannot open shared object file: No such file or directory

ldconfig (w / atau w / o sudo) sayangnya tidak memperbaikinya.

[/] # 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 dari / memberi
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*

Saya sudah mencoba menambahkan /mnt/ext/usr/local/lib ke /etc/ld.so.conf dan _then_ menjalankan ldconfig tanpa hasil.

Seperti inilah sebelumnya (dan saya telah menghapusnya lagi):

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

Apa yang bisa saya lakukan / coba?

@BeyondEvil sudahkah Anda mencoba menggunakan variabel lingkungan LD_LIBRARY_PATH?

@ralcini Tidak, saya belum, (saya pikir). Saya akan mencobanya. 👍

Untuk kueri kompilasi silang di https://github.com/esnet/iperf/issues/153#issuecomment -365012358, saya telah menggunakan make install secara ekstensif. Saya rasa sebagian besar sistem build juga melakukannya - terutama jika sebuah proyek di-autotoolisasi.

Saya sarankan sebagai tikaman pertama ini, proses pembangunan iperf dapat mengeluarkan pesan ke konsol yang menyarankan perintah yang harus dijalankan. Setelah kita memiliki itu, potonglah untuk benar-benar melakukannya.

Apakah ada daftar sistem (* nix) mana yang memerlukan ldconfig untuk dijalankan, dan mana yang tidak? macOS dan Windows termasuk dalam daftar yang tidak memerlukan ldconfig untuk dijalankan setelah make install.

Selain itu, saya ingin tahu sistem mana yang tidak memerlukan ldconfig untuk dijalankan dan bagaimana cara melakukannya.

Penutupan. Ini bukan hanya masalah iperf3, dan sepertinya tidak ada orang lain yang memiliki solusi yang baik untuk itu. (Saya berpendapat bahwa beberapa kombinasi automake dan libtool harus menangani masalah ini.)

Ya, sepertinya masalah libtool. Terakhir kali saya mengejar ini, saya menemukan yang berikut ini di pelacak bug GNU:

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

Pada tahun 1997, komit 7f9b4e50 untuk libtool versi 0.6b, cara menjalankannya
ldconfig diubah dari berjalan tanpa "-n" menjadi berjalan dengan "-n".

Berdasarkan diskusi di sana tampaknya tidak mungkin hal ini akan dikembalikan, karena begitu banyak waktu telah berlalu dan alasan untuk perubahan dan potensi risiko dari perubahan kembali tampaknya kurang dipahami. Jika seseorang menemukan masalah ini di masa mendatang dan tetap ingin mencoba memperbaikinya, itu mungkin hal yang paling mungkin Anda lakukan dengan benar.