Static library — kompilyatsiya qilingan object filelar to‘plami bo‘lib, linker uning kerakli qismlarini build vaqtida bajariladigan fayl yoki boshqa artefakt ichiga qo‘shadi. Unix tizimlarida u ko‘pincha .a, Windowsda .lib kengaytmasiga ega. Natijadagi dastur ishga tushganda shu kutubxona faylining alohida mavjudligiga odatda muhtoj bo‘lmaydi.
Yaratish va linking
Har manba fayl object filega kompilyatsiya qilinadi. Arxiv vositasi objectlarni indeksli kutubxonaga jamlaydi. Linker dasturdagi yechilmagan symbol uchun kutubxona indeksini ko‘rib, zarur object modullarini yakuniy binarga oladi.
source -> object files -> libexample.a
app objects + libexample.a -> executable
Linker ko‘pincha butun kutubxonani emas, kerakli objectni qo‘shadi. Bitta object ichida ishlatilmaydigan funksiyalar ham qolishi mumkin; function sections va dead code elimination ularni yanada mayda darajada olib tashlaydi.
Symbol va tartib
Static linkingda kutubxonalar tartibi muhim bo‘lishi mumkin. Bir passli linker chapdan o‘ngga yurib, ayni paytdagi unresolved symbolni qondiradi. A kutubxonasi Bga bog‘liq bo‘lsa, A odatda Bdan oldin beriladi. Circular dependency group option yoki arxitekturani qayta tashkil etishni talab qiladi.
Bir xil symbol dastur va kutubxonada mavjud bo‘lsa, strong/weak symbol va linker qoidalari qaysi biri tanlanishini belgilaydi. Duplicate strong definition xato beradi. Public header bilan kompilyatsiya qilingan deklaratsiya kutubxonadagi ABIga mos bo‘lishi kerak.
Afzalliklar
Yakuniy artefakt o‘z dependency kodini olib yuradi, deployda mos .so yoki DLL topish muammosi kamayadi. Bitta faylni tarqatish, minimal konteyner yoki embedded tizimda qulay. Kutubxona versiyasi build bilan mahkamlanganligi uchun boshqa paket yangilanishi dasturni kutilmaganda o‘zgartirmaydi.
Link-time optimization kompilyatorga unitlar va kutubxona bo‘ylab inline va dead code optimizatsiyasini bajarish imkonini beradi. Ayrim muhitda static binary recovery vositasi sifatida shared librarylar buzilganda ham ishga tushishi mumkin.
Kamchiliklar
Har executable kutubxona kodining o‘z nusxasiga ega bo‘lib, disk va xotira sarfini oshirishi mumkin. Operatsion tizim shared library kod sahifalarini jarayonlar orasida bo‘lisha oladi; static nusxalar odatda alohida. Katta kutubxona va ko‘p dasturda farq sezilarli bo‘ladi.
Xavfsizlik tuzatishi kutubxona paketini yangilash bilan amaldagi binarlarga avtomatik o‘tmaydi. Kutubxonadan foydalangan har artefakt qayta build, test va deploy qilinishi kerak. SBOM qaysi static komponent qaysi binary ichiga kirganini ko‘rsatishi zarur.
PIC va platforma
Static libraryning o‘zi faqat arxiv; objectlar qaysi flag bilan kompilyatsiya qilingani keyingi ishlatishga ta’sir qiladi. Uni shared library ichiga qo‘shish uchun position-independent code talab qilinishi mumkin. PICsiz object ayrim arxitekturada relocation xatosi yoki text relocation hosil qiladi.
“To‘liq statik” binary ham yadro interfeysi, konfiguratsiya fayli, CA sertifikati yoki name resolution ma’lumotiga bog‘liq bo‘lishi mumkin. Ayrim C library funksiyalari plugin yoki NSS modulini runtime’da yuklaydi. Deploy mustaqilligi amaliy test bilan tekshiriladi.
Litsenziya va build
Ba’zi litsenziyalar static linkingni derivative work yoki qayta link qilish talabi bilan bog‘laydi. Huquqiy majburiyat kutubxona va foydalanish usuliga qarab tekshiriladi. Build system static va dynamic variantni aniq tanlaydi; bir xil nomli fayllar mavjud bo‘lsa, linker defaulti kutilmagan variantni olishi mumkin.
Reproducible build uchun compiler, arxiv formatidagi timestamp, object tartibi va kutubxona versiyasi mahkamlanadi. Deterministic archive metadata turli buildda bir xil hash olishga yordam beradi. Debug symbol alohida faylga chiqarilsa ham binary bilan build ID orqali bog‘lanadi.
Bog‘liq tushunchalar
Dynamic library, Linker, Object file, Symbol resolution, ABI, Position-independent code, Link-time optimization