Hva er ld_library_path brukt til?

Før du kjenner til LD_LIBRARY -banen, bør du ha begrepet miljøvariabler. Men hvis du ikke vet, så ikke bekymre deg, jeg vil forklare hva det er. Variablene hvis verdi bestemmes av operativsystem eller mikroservice -evne kalles miljøvariabler. En miljøvariabel er en dynamisk utpekt verdi som kan påvirke hvordan løpende datamaskinprosesser oppfører seg. Prosess utføres i komponenten i prosessens miljø.

For det første ble miljøvariabler utviklet for UNIX, men nå har Windows og Linux også disse variablene. Når det opprettes noen prosess. Et navn/verdipar utgjør en miljøvariabel, og et hvilket som helst antall av dem kan genereres og refereres til når som helst. Vanlige store bokstaver brukes når du navngir miljøvariabler. Dette hjelper til med å skille miljøvariabler fra andre typer navn i programmeringskode generelt.I UNIX -operativsystem er miljøvariabler case -følsomme, men ikke på DOS, OS/2 eller Windows.

LD_LIBRARY er også en miljøvariabel av UNIX/Linux -operativsystemet; I denne artikkelen vil vi diskutere denne miljøvariabelen i detalj.

Bruk av ld_library_path -variabel

I Unix/Linux -systemet LD_LIBRARY_PATH For å fortelle Dynamic Link Loader, et lite program som begynner alle applikasjonene dine, for å bestemme hvor du skal se etter dynamiske delte biblioteker som en applikasjon var koblet til. En tykktarm (:) skiller en liste over kataloger, og denne listen blir sjekket allerede før innebygd søkevei/stier og konvensjonelle steder som (/lib,/usr/lib ...).

Noen andre bruksområder av LD_LIBRARY_PATH er:

• Sammenligning av nye versjoner av et delt bibliotek med en applikasjon som tidligere er blitt samlet.
• Flytting av delte biblioteker, for eksempel for å holde liv i tidligere versjoner.
• Det brukes også til å lage et selvforsynt system, flyttbart miljø for større applikasjoner, slik at de er uavhengige av endrede systembiblioteker.

Problem med LD_LIBRARY_PATH

Det er veldig nyttig til du prøver å bruke den til å løse problemene dine. Denne linjen virker merkelig, men det er dette som virkelig skjer når du prøver å bruke den i et bruker/systemmiljø, scenariet blir verre og alle miljøvariabler starter avhengig av det og den krasjer ned, da den ikke kan takle alle oppgaver!

Noen problemer ved bruk av LD_LIBRARY_PATH er:

Sikkerhet: Ld_library_path -kataloger blir sjekket først, før deres faktiske beliggenhet. Denne tilnærmingen kan brukes av et ondsinnet individ for å tvinge søknaden din til å kjøre en ondsinnet versjon av et delt bibliotek. En av grunnene til at setuid/setgid kjørbare filer ignorerer at variabelen er på grunn av dette.

Opptreden: Link Loader trenger å se i alle oppgitte kataloger til den finner delte biblioteker (koblet til applikasjon). Følgelig vil flere systemanrop åpne og få dem til å krasje med Enoent ”ingen slik fil eller katalog”. Hvis den spesifiserte banen har mange kataloger, vil den ta lang tid, og du kan sjekke dette fra oppstartstiden for applikasjonen din. Som et resultat vil dette føre til at hele systemet bremser.

Inkonsekvens: Det mest utbredte problemet forårsaket av bruk av LD_LIBRARY_PATH er inkonsekvens. Ld_library_path tvinger et program til å laste inn et delt bibliotek som det ikke var koblet sammen, noe som er veldig helt sikkert uforenlig med originalversjonen. Dette kan være veldig tydelig, for eksempel når applikasjonen krasjer, eller det kan resultere i feil resultater hvis det hentet biblioteket ikke akkurat samsvarer med den opprinnelige versjonens funksjonalitet. Dette vil være tøft å feilsøke sistnevnte, spesielt.

Løsning

Den beste løsningen er jo mindre du bruker den, jo mindre problemer vil du møte. Infact prøver å unngå bruk av LD_LIBRARY_PATH:

Hvordan unngå ld_library_path:

Gi riktig plassering av delt bibliotek: Når du samler applikasjonen din, må du gi nøyaktig plassering av delte biblioteker og spesifisere banen i alternativet '-RPATH' Linker for å informere linkeren om å inkludere dem til din kjørbare runpath, eller du kan bruke LD_RUN_PATH-variabelen for å spesifisere flere baner

Verktøy for å fikse problem:For å fikse/endre runpath for en binær kjørbar, er det programmer tilgjengelig, for eksempel Chrpath under Linux. Problemet på denne måten er at det kjørbare rommet som bærer denne informasjonen (i.e. banestrengen) kan ikke utvides, jeg.e. Du kan bare omskrive en eksisterende bane.

Ikke sett LD_LIBRARY_PATH i brukerprofil: Ved å sette ld_library_path i brukerprofilen vil du skape problemer for deg selv, så unngå dette.

Ikke sett LD_LIBRARY_PATH i systemprofilen: Noen ISV -er gir programvare som automatisk setter inn globale LD -bibliotekstiinnstillinger i systemprofiler under installasjonen, eller til og med ber brukeren om å gjøre det. Bare si nei! Prøv å håndtere problemet på en annen måte, for eksempel ved å skrive et innpakningsskript, eller be leverandøren om å rette det opp.

LD_LIBRARY_PATH er nyttig hvis det brukes til tre bruksområder som er nevnt i bruksdelen, men prøv å bruke den så lite som mulig for å beskytte deg mot å komme i trøbbel.

Konklusjon

LD_LIBRARY_PATH er en miljøvariabel brukt i Linux/UNIX -systemer. Det brukes til å fortelle dynamiske lenkerelaster hvor de skal se etter delte biblioteker for spesifikke applikasjoner. Det er nyttig før du ikke roter med det. Det er bedre å unngå bruk av ld_library_path og bruke alternativer. I denne artikkelen blir bruken av LD_LIBRARY_PATH miljøvariabel diskutert, og deretter blir problemet med bruken av det diskutert og deretter løsningen. Etter å ha lest denne artikkelen vil du bli kjent med fordeler og ulemper med LD_LIBRARY_PATH -variabelen.