Static linking — dasturga kerakli kutubxona kodini build vaqtida executable ichiga qo‘shish usulidir. Linker object file va static library arxivlaridan kerakli symbollarni tanlab, relocationlarni hal qiladi. Natijada executable ko‘p dependency uchun runtime’da alohida shared library topishga muhtoj bo‘lmaydi. Bu deploymentni soddalashtirishi mumkin, lekin hajm, update va litsenziya oqibatlariga ega.
Linker ishlashi
Compiler har source unit’dan object file yaratadi. Unda definition, unresolved symbol va relocation yozuvlari bo‘ladi. Static library odatda object file’lar arxividir. Linker command line’dagi tartib va symbol ehtiyojiga qarab kerakli memberlarni chiqarib, addresslarni yakuniy layoutga bog‘laydi.
Dead-code elimination foydalanilmagan sectionlarni olib tashlashi mumkin. Link-time optimization bir nechta module IR’ini birga ko‘rib, cross-module inlining va optimallashtirish bajaradi. Biroq dynamic lookup yoki plugin orqali ishlatiladigan symbol aniq root sifatida ko‘rsatilmasa tasodifan olib tashlanishi mumkin.
Static va dynamic farqi
Dynamic linking’da executable import table saqlaydi, loader runtime’da shared libraryni topadi. Bir library kodi bir nechta process orasida memory page sifatida bo‘linishi va security patch bitta paket bilan yangilanishi mumkin. Static binary har executable’da o‘z nusxasiga ega va dependency resolution deploy paytida kamayadi.
To‘liq static tushunchasi platformaga bog‘liq. Dastur static compile qilingan bo‘lsa ham kernel, DNS resolver data, timezone yoki certificate store kabi tashqi runtime resursiga tayanishi mumkin. Ayrim system frameworklar static linkni qo‘llamaydi. “Bitta fayl” mutlaq mustaqillik kafolati emas.
Afzallik va xarajat
Container yoki minimal recovery muhitida static binary library mismatchni kamaytiradi. Startup loader kamroq ish bajarishi mumkin. Har servis o‘z dependency versiyasini olib yuradi, shuning uchun hostdagi global update kutilmagan ABI buzilishi yaratmaydi.
Buning evaziga binary kattalashadi va umumiy library kodi disk hamda memoryda takrorlanadi. Eng muhim xavf patch boshqaruvidir: static bog‘langan zaif library OS package update bilan tuzalmaydi. Uni ishlatgan har application qayta build, test va deploy qilinishi kerak. SBOM binary ichidagi componentni aniq ko‘rsatadi.
ABI, plugin va litsenziya
Static link internal calllarni optimallashtirishi mumkin, ammo public plugin ABI alohida qoladi. Plugin host bilan boshqa allocator ishlatsa xotirani qaysi tomon bo‘shatishi aniq belgilanadi. Symbol collision va duplicate runtime global state murakkab xatolar keltirishi mumkin.
Kutubxona litsenziyasi static linking uchun alohida majburiyat qo‘yishi ehtimoli bor. Source yoki relink imkonini berish talabi huquqiy tekshiruvdan o‘tadi. Build pipeline library source, version, flag va license metadata’ni artifact bilan saqlaydi.
Security hardening
Static binary ham position-independent executable, stack protector va control-flow protection bilan qurilishi mumkin. Compiler hamda linker flaglari yakuniy artifactda tekshiriladi, chunki bitta object hardening’siz compile qilingan bo‘lishi mumkin. Duplicate library versiyalari turli symbol namespace’da yashirin qolsa scanner package nomidan tashqari binary fingerprintga tayanadi. FIPS yoki boshqa validated cryptographic module statik bog‘langanda build konfiguratsiyasi validation chegarasiga ta’sir qilishi mumkin. Hot patch shared libraryni almashtirish orqali bajarilmaydi; butun executable yangilanadi. Atomic deploy, process restart va rollback service availability rejasining qismidir.
Build artifactdagi library versiyasi source manifest bilan avtomatik solishtiriladi.
Bog‘liq tushunchalar
Dynamic linking, Linker, Static library, Shared library, ABI, Link-time optimization, SBOM