Apa itu file .so.2?

Biasanya ketika Anda membangun objek bersama (.so) maka Anda juga menjaga versi dengan menambahkan sufiks seperti mylib.so.2.3.1. Untuk memastikan program Anda dapat memuat lib ini atau versi lain yang lebih baru, Anda membuat tautan dengan nama

mylib.so -> mylib.so.2.3.1
mylib.so.2 -> mylib.so.2.3.1
mylib.so.2.3 -> mylib.so.2.3.1

Jadi, semuanya setelah .so mewakili versi.sub-versi.bangun (atau serupa)Juga, dimungkinkan untuk lebih dari satu versi lib yang sama untuk hidup berdampingan dengan skema ini, dan semua yang diperlukan untuk mengalihkan program ke penggunaan tertentu versi adalah memiliki tautan yang sesuai.

Biner ELF yang ditautkan secara dinamis (apakah perpustakaan lain atau yang dapat dieksekusi) menggunakan nama objek bersama atau soname untuk mengidentifikasi perpustakaan yang harus ditautkan dengan executable setelah eksekusi.

Ketika perpustakaan dibuat sebagai perpustakaan bersama ELF, editor tautan waktu kompilasi menyisipkan bidang DT_SONAME di executable yang berisi SONAME perpustakaan ke dalam perpustakaan itu sendiri. DT_SONAME didefinisikan dalam standar ELF sebagai:

Elemen ini menyimpan offset tabel string dari string yang diakhiri null, memberikan nama objek bersama. Offset adalah indeks ke dalam tabel yang direkam dalam DT_STRTAB pintu masuk. Lihat ‘‘Shared ObjectDependencies’’ di bawah untuk informasi selengkapnya tentang nama-nama ini.

Jadi sekarang ketika sebuah executable dibuat, SONAME disematkan ke dalamnya. Ketika ketika executable dijalankan digunakan oleh linker untuk mencari perpustakaan di file di lokasi yang telah ditentukan sebelumnya untuk perpustakaan dinamis. Lokasi yang telah ditentukan sebelumnya di windows adalah di mana pun DLL berada. Di Linux dan Mac OS X dan sistem lain yang kompatibel dengan Sistem V, mereka akan menjadi /lib dan /usr/lib dan mungkin tempat lain, tergantung pada penaut yang digunakan, dan dapat ditentukan dalam konfigurasi penaut itu sendiri.

Dalam semua kejadian, penaut melihat apakah perpustakaan yang disebutkan dalam entri soname ada di salah satu lokasi tersebut, jika itu akan digunakan.

Perhatikan bahwa standar mengatakan bahwa soname adalah STRING dan konvensi pembuatan versi menjadi standar defacto setelah fakta dan berjalan seperti ini:

Buat soname menjadi libmyname.so.A dan jadikan nama file perpustakaan menjadi libmyname.so.A.B atau libmyname.so.A.B.C (di bawah MacOSX ini adalah libmyname.A.B.dylib). Buat softlink dari libmyname.so.A.B[.C]? ke libmyname.so.A .

A tetap sama sementara ABI perpustakaan tetap sama.

B (atau B.C ) menjadi versi minor.

Di Linux, sangat umum bahwa versi pustaka akan sama dengan nomor versi paket. Ini memiliki pro dan kontra.

formalisasi libtool

Libtool GNU banyak digunakan untuk membangun perpustakaan dinamis, dan memiliki sistem versi yang lebih formal dan memiliki logika yang kuat untuk itu. Sistem versi libtool untuk soname bekerja dengan sangat baik dan diadopsi oleh pustaka kompleks untuk menjaga semuanya tetap lurus.

Di bawah libtool, pembuatan versi adalah sebagai berikut:

libmylib-saat ini .rilis .usia

Di bawah libtool, idenya adalah seiring berkembangnya pustaka, mereka akan menambah dan menghapus fungsionalitas.

Katakanlah Anda sedang mengembangkan perpustakaan. Mulailah dengan menggunakan versi sebagai 0.0.0 .

Sekarang katakanlah Anda memperbaiki beberapa bug, Anda hanya akan meningkatkan rilis nomor.

Jadi nama baru akan menjadi libmylib.0.1.0 atau libmylib.0.2.0 dll.. untuk setiap rilis yang hanya memperbaiki bug tetapi tidak mengubah ABI apa pun.

Sepanjang jalan Anda mengatakan. Aduh! Saya dapat melakukan subfungsi ini dengan lebih baik. Jadi, Anda menambahkan serangkaian fungsi baru untuk melakukan sesuatu dengan lebih baik, tetapi karena yang lain masih menggunakan pustaka Anda, Anda masih membiarkan fungsi lama (yang sudah tidak digunakan lagi) di sana.

Aturannya adalah sebagai berikut:

1. Mulailah dengan informasi versi '0:0:0' untuk setiap pustaka libtool.

2. Perbarui informasi versi hanya segera sebelum rilis publik perangkat lunak Anda. Pembaruan yang lebih sering tidak diperlukan, dan hanya menjamin bahwa nomor antarmuka saat ini menjadi lebih besar dengan lebih cepat.

3. Jika kode sumber pustaka telah berubah sama sekali sejak pembaruan terakhir, maka revisi bertahap ('c:r:a' menjadi 'c:r+1:a').

4. Jika ada antarmuka yang telah ditambahkan, dihapus, atau diubah sejak pembaruan terakhir, tingkatkan arus, dan setel revisi ke 0.

5. Jika ada antarmuka yang telah ditambahkan sejak rilis publik terakhir, maka tingkatkan usia.

6. Jika ada antarmuka yang telah dihapus atau diubah sejak rilis publik terakhir, setel usia ke 0.

Anda dapat membaca selengkapnya di dokumentasi libtool

Perbarui ...

Berikut ini adalah komentar bahwa penjelasan saya memiliki kesalahan. Itu tidak, yang membutuhkan sedikit lebih banyak detail daripada yang dapat dimasukkan ke dalam komentar jawaban, jadi lihat di bawah.

Keberatan awal

Ada kesalahan di sini:di linux, versinya adalah formlibmylib.(current-age).release.age, di mana tanda kurung menunjukkan ekspresi yang akan dievaluasi. Misalnya GLPK 4.54 withcurrent:revision:age =37:1:1 di linux instal library filelibglpk.so.36.1.1. Untuk info selengkapnya, lihat, misalnya,.

Sangkalan

TLDR:autotools.io bukan sumber resmi. Penjelasan

Sementara Flameeyes adalah pengembang yang luar biasa dan dia adalah salah satu pengelola Gentoo, itu adalah dia yang membuat kesalahan, dan membuat interpretasi longgar "aturan umum" dari spesifikasi libtool. Meskipun ini tidak akan merusak sistem 99% dari waktu, jika kita mengikuti cara ad-hoc memperbarui saat ini :

Aturan praktisnya, saat menangani nilai-nilai ini adalah:

Selalu tingkatkan nilai revisi.

Tingkatkan nilai saat ini setiap kali antarmuka ditambahkan, dihapus, atau diubah.

Tingkatkan nilai usia hanya jika perubahan yang dilakukan pada ABI kompatibel dengan versi sebelumnya.

dia kemudian melanjutkan dengan mengatakan bahwa mempertahankan beberapa versi Gtk akan lebih baik jika hanya menambahkan versi perpustakaan ke dalam NAMA perpustakaan dan hanya membuang nomor versinya. (seperti yang mereka lakukan di GTK+):

Dalam situasi ini, opsi terbaik adalah menambahkan bagian dari informasi versi perpustakaan ke nama perpustakaan, yang dicontohkan oleh soname libglib-2.0.so.0 Glib. Untuk melakukannya, deklarasi di theMakefile.am harus seperti ini:

lib_LTLIBRARIES = libtest-1.0.la

libtest_1_0_la_LDFLAGS = -version-info 0:0:0

Nah, itu hanya pendekatan crockpot untuk menghilangkan kekuatan tautan dinamis dan versi resolusi simbol yang sepenuhnya diperdebatkan!. Dia bilang matikan saja. Kuda booger! Tidak heran bahkan developer berpengalaman mengalami kesulitan membangun dan memelihara proyek sumber terbuka dan kami terus-menerus mengalami kematian binari setiap kali versi pustaka baru diinstal (karena mereka saling mengalahkan).

Pendekatan pembuatan versi libtool adalah DIPIKIRKAN DENGAN SANGAT BAIK . Ini adalah algoritme dan langkah-langkahnya diurutkan petunjuk 1 ke 6 harus diikuti setiap kali ada pembaruan pada kode pustaka tertaut dinamis.

Untuk pengembang baru dan saat ini, harap baca dengan cermat dan visualisasikan apa yang akan terjadi pada nomor versi perpustakaan selama masa pakai perangkat lunak Anda yang luar biasa. Jika Anda melakukannya, Anda akan melihat bahwa setiap perangkat lunak yang ditautkan sebelumnya akan selalu menggunakan versi terbaru dan akurat dari perpustakaan Anda yang luar biasa dengan benar, dan tidak satu pun akan pernah memukul atau menginjak satu sama lain, DAN Anda tidak perlu menambahkan nomor mekar atas nama perpustakaan Anda (kecuali untuk kesenangan atau estetika).