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.4.0 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.4.0). 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.