Biblioteker: Statisk eller delt?

Biblioteker: Statisk eller delt?

De originale bibliotekene var rett og slett et arkiv av rutiner som de nødvendige rutinene ble trukket ut fra og koblet inn i det kjørbare programmet. Disse beskrives som statiske biblioteker, med navn på formen libfoo.a på UNIX lignende operativsystemer. På noen gamle operativsystemer er de den eneste tilgjengelige typen.

På nesten alle Linux plattformer er det også «delte» (eller tilsvarende «dynamiske») biblioteker (med navn på formen libfoo.so) – en kopi av biblioteket lastes inn i det virtuelle minnet, og deles av alle programmene som kaller noen av funksjonene. Dette er plass effektiv.

Tidligere ble essensielle programmer som et skall ofte koblet sammen statisk slik at en form for minimalt gjenopprettingssystem til og med ville eksistere hvis delte biblioteker, som f.eks libc.so, ble skadet (f.eks. flyttet til lost+found av fsck etter en uren nedstengning). Nå for tiden, de fleste bruker en alternativ systeminstallasjon eller en USB pinne hvis de må gjenopprette. Journalføring av filsystemer reduserer også sannsynligheten for denne typen problem.

Inne i boken er det forskjellige steder hvor konfigureringsbrytere som for eksempel --disable-static er brukt, og andre steder hvor muligheten for å bruke systemversjoner av biblioteker i stedet for versjonene som er inkludert i en annen pakke er diskutert. Hovedgrunnen til dette er å forenkle oppdateringer av biblioteker.

Hvis en pakke er koblet til et dynamisk bibliotek, oppdatering til et nyere bibliotekversjon er automatisk når det nyere biblioteket er installert og programmet (på nytt) startes (forutsatt at bibliotekets hovedversjon er uendret, f.eks. går fra libfoo.so.2.0 til libfoo.so.2.1. Gå til libfoo.so.3 vil kreve rekompilering – ldd kan brukes til å finne hvilke programmer som bruker den gamle versjonen). Hvis et program er knyttet til et statisk biblioteket, må programmet alltid kompileres på nytt. Hvis du vet hvilke programmer som er knyttet til et bestemt statisk bibliotek, er dette bare en irritasjon. Men vanligvis vil du ikke vite hvilke programmer å rekompilere.

En måte å identifisere når et statisk bibliotek brukes, er å håndtere det på slutten av installasjonen av hver pakke. Skriv et skript for å finne alle de statiske bibliotekene i /usr/lib eller hvor enn du installerer til, og enten flytte dem til en annen mappe slik at de er ikke lenger blir funnet av linkeren, eller gi dem nytt navn slik at libfoo.a blir f.eks. libfoo.a.hidden. Det statiske biblioteket kan da midlertidig gjenopprettes hvis det noen gang er nødvendig, og pakken som trenger det kan identifiseres. Dette bør ikke gjøres blindt siden mange biblioteker eksisterer bare i en statisk versjon. For eksempel noen biblioteker fra glibc og gcc pakkene skal alltid være presentert på systemet som (libc_nonshared.a, libg.a, libpthread_nonshared.a, libssp_nonshared.a, libsupc++.a fra glibc-2.36 og gcc-12.2).

Hvis du bruker denne tilnærmingen, kan du oppdage at flere pakker enn du ventet bruker et statisk bibliotek. Det var tilfellet med nettle-2.4 i standard kun statisk konfigurasjon: Det ble påkrevd av GnuTLS-3.0.19, men også koblet til pakke(r) som bruker GnuTLS, som for eksempel glib-networking-2.32.3.

Mange pakker legger noen av sine vanlige funksjoner inn i et statisk bibliotek som bare brukes av programmene i pakken og, avgjørende, biblioteket er ikke installert som en frittstående bibliotek. Disse interne bibliotekene er ikke et problem – hvis pakken må bygges om for å fikse en feil eller sårbarhet, ingenting annet er knyttet til dem.

Når BLFS nevner systembiblioteker, betyr det delte versjoner av biblioteker. Noen pakker som f.eks Firefox-128.3.1 og ghostscript-10.04.0 samler mange andre biblioteker i byggetreet deres. Versjonen de sender er ofte eldre enn versjonen som brukes i systemet, så det kan inneholde feil – noen ganger tar utviklere bryet med å fikse feil i de inkluderte bibliotekene, andre ganger gjør de det ikke.

Noen ganger er det en enkel avgjørelse å bestemme seg for å bruke systembiblioteker. Andre ganger kan det kreve at du endrer systemversjonen (f.eks libpng-1.6.44 hvis det brukes til Firefox-128.3.1). Noen ganger sender en pakke et gammelt bibliotek og kan ikke lenger koble til gjeldende versjon, men kan lenke til en eldre versjon. I dette tilfellet, BLFS vil vanligvis bare bruke den leverte versjonen. Noen ganger det er det inkluderte biblioteket ikke lenger utviklet separat, eller oppstrøms er nå det samme som pakkens oppstrøms og du har ingen andre pakker som vil bruke den. I slike tilfeller vil du bli ledet til å bruke det inkluderte biblioteket selv om du vanligvis foretrekker å bruke systembiblioteker.