Sådan installeres software fra kildekoden ... og fjernes bagefter

Før eller siden bliver du nødt til at kompilere noget software fra kilder. Denne artikel guider dig gennem den (ikke så) episke rejse ved at vise dig, hvordan du kompilerer og installerer NodeJS fra bunden på Debian- og Red-Hat/CentOS-baserede systemer.



Kort: Denne detaljerede vejledning forklarer, hvordan man installerer et program fra kildekoden i Linux, og hvordan man fjerner den software, der er installeret fra kildekoden.

En af de største styrker ved din Linux -distribution er dens pakkehåndtering og det tilhørende softwarelager. Med dem har du alle de nødvendige værktøjer og ressourcer til at downloade og installere ny software på din computer på en helt automatiseret måde.





Men på trods af al deres indsats kan pakkeholderne ikke håndtere alle brugssager. De kan heller ikke pakke al den tilgængelige software derude. Så der er stadig situationer, hvor du selv skal kompilere og installere ny software. Hvad mig angår, er den mest almindelige årsag langt, at jeg skal kompilere noget software, når jegbrug forat køre en meget specifik version eller ændre kildekoden ved hjælp af nogle flotte kompilationsmuligheder.

Hvis dinbehovtilhører sidstnævnte kategori, er chancerne for, at du allerede ved, hvad du skal gøre. Men for langt de fleste Linux -brugere kan kompilering og installation af software fra kildekoden for første gang ligne en indledende ceremoni: noget skræmmende; men med løftet om at komme ind i en ny verden af ​​muligheder og et sted for prestige i et privilegeret fællesskab.



ubuntu skrive iso til usb

A. Installation af software fra kildekoden i Linux

Og det er præcis, hvad vi vil gøre her. I forbindelse med denne artikel, lad os sige, at jeg skal installere NodeJS 8.1.1 på mit system. Den version præcis. En version, der ikke er tilgængelig fra Debian -arkivet:

sh$ apt-cache madison nodejs | grep amd64 nodejs | 6.11.1~dfsg-1 | http://deb.debian.org/debian experimental/main amd64 Packages nodejs | 4.8.2~dfsg-1 | http://ftp.fr.debian.org/debian stretch/main amd64 Packages nodejs | 4.8.2~dfsg-1~bpo8+1 | http://ftp.fr.debian.org/debian jessie-backports/main amd64 Packages nodejs | 0.10.29~dfsg-2 | http://ftp.fr.debian.org/debian jessie/main amd64 Packages nodejs | 0.10.29~dfsg-1~bpo70+1 | http://ftp.fr.debian.org/debian wheezy-backports/main amd64 Packages

Nu, installation af NodeJs på Ubuntu eller Debian er ret simpelt, hvis du gør det med pakkehåndteringen. Men lad os gøre det via kildekoden.

Trin 1: Hent kildekoden fra GitHub

Ligesom mange open source-projekter kan kilderne til NodeJS findes på GitHub: https://github.com/nodejs/node

Så lad os gå direkte dertil.

NodeJS officielle GitHub -lager

Hvis du ikke er bekendt med GitHub , eller andre versionskontrolsystem værd at nævne depotet indeholder den aktuelle kilde til softwaren samt en historik over alle de ændringer, der er foretaget gennem årene til softwaren. Til sidst op til den allerførste linje skrevet til det projekt. For udviklerne har det mange fordele at beholde den historie. For os i dag er den vigtigste, at vi vil være i stand til at hente kilderne til projektet, som de var på et givet tidspunkt. Mere præcist vil jeg kunne få kilderne, som de var, da den 8.1.1 -version, jeg ønsker, blev frigivet. Selvom der var mange ændringer siden.

Vælg v8.1.1 -tagget i NodeJS GitHub -depotet

På GitHub kan du bruge grenknappen til at navigere mellem forskellige versioner af softwaren. Gren og tags er noget relaterede begreber i Git . Grundlæggende opretter udviklerne filialer og tags for at holde styr på vigtige begivenheder i projekthistorikken, f.eks. Når de begynder at arbejde på en ny funktion eller når de udgiver en udgivelse. Jeg vil ikke gå ind på detaljerne her, alt hvad du behøver at vide er, at jeg leder efter versionen markeret v8.1.1

NodeJS GitHub -depotet, som det var på det tidspunkt, v8.1.1 -tagget blev oprettet

Efter at have valgt på v8.1.1 -taggen, opdateres siden, idet den mest oplagte ændring er, at tagget nu vises som en del af webadressen. Derudover vil du bemærke, at filændringsdatoen også er anderledes. Kildetræet, du nu ser, er det, der eksisterede på det tidspunkt, v8.1.1 -tagget blev oprettet. På en eller anden måde kan du tænke på et versionskontrolværktøj som git som en tidsrejsemaskine, så du kan gå frem og tilbage i en projekthistorik.

NodeJS GitHub -arkiv downloades som en ZIP -knap

På dette tidspunkt kan vi downloade kilderne til NodeJS 8.1.1. Du kan ikke gå glip af den store blå knap, der foreslår at downloade projektets ZIP -arkiv. Hvad mig angår, vil jeg downloade og udtrække ZIP fra kommandolinjen af ​​hensyn til forklaringen. Men hvis du foretrækker at bruge en GUI værktøj, tøv ikke med at gøre det i stedet:

wget https://github.com/nodejs/node/archive/v8.1.1.zip unzip v8.1.1.zip cd node-8.1.1/

At downloade ZIP -arkivet fungerer godt. Men hvis du vil gøre det som en proff, vil jeg foreslå at bruge direkte | _+_ | værktøj til at downloade kilderne. Det er slet ikke kompliceret - og det vil være en dejlig første kontakt med et værktøj, du ofte vil støde på:

git

Forresten, hvis du har et problem, skal du bare overveje den første del af detteartikelsom en generel introduktion. Senere har jeg mere detaljerede forklaringer på Debian- og RedHat-baserede distributioner for at hjælpe dig med at fejlfinde almindelige problemer.

Anyway, når du downloadede kilden ved hjælp af | _+_ | eller som et ZIP -arkiv, skal du nu have nøjagtig de samme kildefiler i det aktuelle bibliotek:

# first ensure git is installed on your system sh$ sudo apt-get install git # Make a shallow clone the NodeJS repository at v8.1.1 sh$ git clone --depth 1 --branch v8.1.1 https://github.com/nodejs/node sh$ cd node/

Trin 2: Forstå programmets Build System

Vi taler normalt om at kompilere kilderne, men kompilationen er kun en af ​​de faser, der kræves for at producere en fungerende software fra dens kilde. Et build -system er et sæt værktøjer og praksis, der bruges til at automatisere og artikulere de forskellige opgaver for helt at bygge softwaren bare ved at udsende få kommandoer.

Hvis konceptet er enkelt, er virkeligheden noget mere kompliceret. Fordi forskellige projekter eller programmeringssprog kan have forskellige krav. Eller på grund af programmørens smag. Eller de understøttede platforme. Eller af historisk grund. Eller… eller .. der er en næsten endeløs liste over grunde til at vælge eller oprette et andet byggesystem. Alt det at sige, der er mange forskellige løsninger, der bruges derude.

NodeJS bruger en Byggesystem i GNU-stil , det er et populært valg i open source -fællesskabet og endnu en gang en god måde at starte din rejse på.

At skrive og indstille et byggesystem er en temmelig kompleks opgave, men for slutbrugeren letter byggesystemer i GNU-stil opgaven ved hjælp af to værktøjer: | _+_ | og | _+_ |.

Den | _+_ | fil er et projektspecifikt script, der kontrollerer destinationssystemkonfigurationen og den tilgængelige funktion for at sikre, at projektet kan bygges og i sidste ende omhandler specifikationerne for den nuværende platform.

En vigtig del af en typisk | _+_ | opgaven er at bygge | _+_ |. Det er filen, der indeholder de instruktioner, der kræves for effektivt at bygge projektet.

butikken åbner ikke windows 10

Det | _+_ | værktøj på den anden side er et POSIX-værktøj tilgængeligt på ethvert Unix-lignende system. Det vil læse den projektspecifikke | _+_ | og udfør de nødvendige operationer for at bygge og installere dit program.

Men som altid i Linux -verdenen har du stadig en vis lethed i at tilpasse bygningen til din specifikkebehov.

git

Den | _+_ | kommandoen viser dig alle de tilgængelige konfigurationsmuligheder. Endnu en gang er dette meget projektspecifikt. Og for at være ærlig, er det nogle gange nødvendigt at grave ind i projektet, før du fuldt ud forstår betydningen af ​​hver konfigurationsindstilling.

Men der er mindst en standard GNU Autotools -indstilling, som du skal kende: | _+_ | mulighed. Dette har at gøre med filsystemhierarkiet og det sted, hvor din software vil blive installeret.

Trin 3: FHS

Linux -filsystemhierarkiet på en typisk distribution overholder for det meste Filsystem Hierarchy Standard (FHS)

Denne standard forklarer formålet med de forskellige telefonbøger i dit system: | _+_ |, | _+_ |, | _+_ | og så videre.

Når du bruger GNU Autotools - og de fleste andre build -systemer - vil standardinstallationsplaceringen for din nye software være | _+_ |. Hvilket er et godt valg ifølge FSH /Usr /local hierarchy er til brug for systemadministratoren ved installation af software lokalt? Det skal være sikkert fra at blive overskrevet, når systemsoftwaren opdateres. Det kan bruges til programmer og data, der kan deles blandt en gruppe værter, men ikke findes i /usr.

Den | _+_ | hierarki replikerer på en eller anden måde rodmappen, og du finder der | _+_ | for de eksekverbare programmer, | _+_ | for bibliotekerne, | _+_ | til arkitekturuafhængige filer og så videre.

Det eneste problem ved brug af | _+_ | træ til brugerdefineret softwareinstallation er filerne til al din software blandet der. Især efter at have installeret et par software, vil det være svært at spore til hvilken fil nøjagtigt | _+_ | og | _+_ | tilhører hvilken software. Det vil dog ikke forårsage problemer for systemet. Trods alt | _+_ | er omtrent det samme rod. Men det bliver et problem den dag, du vil fjerne en manuelt installeret software.

For at løse dette problem foretrækker jeg normalt at installere brugerdefineret software i | _+_ | undertræ i stedet. Endnu en gang, for at citere FHS:

_/opt er forbeholdt installation af add-on applikationssoftwarepakker.

En pakke, der skal installeres i /opt, skal lokalisere sine statiske filer i et separat /opt /eller /opt /biblioteketræ, hvor er et navn, der beskriver softwarepakken og er udbyderens LANANA -registrerede navn.

Så vi opretter en undermappe af | _+_ | specifikt til vores brugerdefinerede NodeJS -installation. Og hvis jeg en dag vil fjerne denne software, bliver jeg simpelthen nødt til at fjerne det bibliotek:

sh$ ls android-configure BUILDING.md common.gypi doc Makefile src AUTHORS CHANGELOG.md configure GOVERNANCE.md node.gyp test benchmark CODE_OF_CONDUCT.md CONTRIBUTING.md lib node.gypi tools BSDmakefile COLLABORATOR_GUIDE.md deps LICENSE README.md vcbuild.bat

Alt andet end ok efter | _+_ | kommandoen er udført, ville betyde, at der var en fejl under byggeprocessen. Da vi kørte en parallel build på grund af | _+_ | valgmulighed, er det ikke altid let at hente fejlmeddelelsen i betragtning af den store mængde output, der produceres af build -systemet.

I tilfælde af et problem skal du bare genstarte | _+_ |, men uden | _+_ | mulighed denne gang. Og fejlen skulle vises nær slutningen af ​​output:

configure

Endelig, når kompilationen er gået til ende, kan du installere din software til dens placering ved at køre kommandoen:

make

Og test det:

configure

B. Hvad hvis det går galt, når du installerer fra kildekoden?

Det, jeg har forklaret ovenfor, er for det meste det, du kan se på build-instruktionssiden for et veldokumenteret projekt. Men da denne artikels mål er at lade dig kompilere din første software fra kilder, kan det være værd at tage sig tid til at undersøge nogle almindelige problemer. Så jeg vil gøre hele proceduren igen, men denne gang fra et nyt og minimalt Debian 9.0 og CentOS 7.0 systemer, så du kan se de fejl, jeg stødte på, og hvordan jeg løste dem.

Fra Debian 9.0 Stretch

configure

Dette problem er ret let at diagnosticere og løse. Bare installer | _+_ | pakke:

Makefile make Makefile

Intet problem her.

./configure --help

Det er klart, at for at kompilere et projekt, har du brug for en kompilator. NodeJS skrives ved hjælp af C ++ sprog , vi har brug for en C ++ kompilator . Her vil jeg installere `g ++`, GNU C ++ - kompilatoren til dette formål:

configure -help --prefix

Et andet værktøj mangler. Samme symptomer. Samme løsning:

/usr /tmp

Succes!

Bemærk: Jeg har installeret de forskellige værktøjer et efter et for at vise, hvordan du diagnosticerer kompilationsproblemerne og viser dig den typiske løsning til at løse disse problemer. Men hvis du søger efter mere information om emnet eller læser andre selvstudier, vil du opdage, at de fleste distributioner har metapakker, der fungerer som en paraply til at installere nogle eller alle de typiske værktøjer, der bruges til at kompilere en software. På Debian-baserede systemer vil du sandsynligvis støde på build-essentials pakke til det formål. Og på Red-Hat-baserede distributioner vil det være Udviklingsværktøjer gruppe.

Fra CentOS 7.0

/var

Kommando ikke fundet? Bare installer det ved hjælp af | _+_ | pakkeleder:

/usr/local /usr/local /usr/local/bin /usr/local/lib

Du gætter det: NodeJS er skrevet ved hjælp af C ++ - sproget, men mit system mangler den tilsvarende compiler. Nøj til undsætning. Da jeg ikke er en almindelig CentOS -bruger, var jeg faktisk nødt til at søge på internettet det nøjagtige navn på den pakke, der indeholder g ++ - kompilatoren. Leder mig til den side: https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

/usr/local/share /usr/local /usr/local/bin /usr/local/lib

Succes. Igen.

C. Foretag ændringer af softwaren installeret fra kildekoden

Du må installere software fra kilden, fordi dubrug foren meget specifik version ikke tilgængelig i dit distributionslager, eller fordi du vil ændre programmet for at rette en fejl eller tilføje en funktion. Open-source handler jo om at foretage ændringer. Så jeg vil benytte lejligheden til at give dig en forsmag på den magt, du har til rådighed, nu hvor du er i stand til at kompilere din egen software.

Her vil vi foretage en mindre ændring af kilderne til NodeJS. Og vi vil se, om vores ændring vil blive inkorporeret i den kompilerede version af softwaren:

Åbn filen | _+_ | i din favorit teksteditor (vim, nano, gedit, ...). Og prøv at finde det fragment af kode:

Hent youtube -videoer linux
/usr/bin

Det er rundt fil 3830 i filen . Rediger derefter linjen, der indeholder | _+_ | for at matche den i stedet:

/opt

Gå derefter tilbage til din terminal. Inden du går videre - og for at give dig mere indsigt i kraften bag git - kan du kontrollere, om du har ændret den rigtige fil:

/opt

Du bør se et - (minustegn) før linjen, som den var, før du ændrede den. Og et + (plustegn) før linjen efter dine ændringer.

Det er nu tid til at kompilere og geninstallere din software:

sh$ sudo mkdir /opt/node-v8.1.1 sh$ sudo ln -sT node-v8.1.1 /opt/node # What is the purpose of the symbolic link above? # Read the article till the end--then try to answer that # question in the comment section! sh$ ./configure --prefix=/opt/node-v8.1.1 sh$ make -j9 && echo ok # -j9 means run up to 9 parallel tasks to build the software. # As a rule of thumb, use -j(N+1) where N is the number of cores # of your system. That will maximize the CPU usage (one task per # CPU thread/core + a provision of one extra task when a process # is blocked by an I/O operation.

Denne gang er den eneste grund til at det mislykkes, at du har lavet en tastefejl, mens du ændrede koden. Hvis dette er tilfældet, skal du åbne | _+_ | fil i din tekstredigerer, og rett fejlen.

Når du har formået at kompilere og installere den nye modificerede NodeJS -version, vil du være i stand til at kontrollere, om dine ændringer faktisk var indarbejdet i softwaren:

make

Tillykke! Du har foretaget din første ændring af et open source-program!

D. Lad skallen finde vores specialbyggede software

Du har muligvis bemærket, at jeg altid har lanceret min nyligt sammensatte NodeJS -software ved at angive den absolutte vej til den binære fil.

-j

Det virker. Men det er mildest talt irriterende. Der er faktisk to almindelige måder at reparere det på.

Der er faktisk to almindelige måder at løse det irriterende problem med at specificere den absolutte vej til de binære filer,
men for at forstå dem skal du først vide, at din shell lokaliserer de eksekverbare filer ved kun at kigge efter dem i de mapper, der er angivet af PATH miljøvariabel .

make

Her på det Debian -system, hvis du ikke eksplicit angiver nogen mappe som en del af et kommandonavn, søger skallen først efter de eksekverbare programmer i | _+_ |, derefter hvis den ikke findes i | _+_ |, derefter hvis det ikke findes i | _+_ | så hvis det ikke findes i | _+_ | så hvis den ikke findes i | _+_ |, så hvis den ikke findes ... vil skallen rapportere en fejl Kommando ikke fundet .

I betragtning af det har vi to måder at gøre en kommando tilgængelig for skallen: ved at tilføje den til en af ​​de allerede konfigurerede | _+_ | mapper. Eller ved at tilføje biblioteket indeholdende vores eksekverbare fil til | _+_ |.

Lige kopiering node binær eksekverbar fra | _+_ | til | _+_ | ville være en dårlig idé, da det ved at gøre det, det eksekverbare program ikke længere ville være i stand til at finde de andre nødvendige komponenter, der tilhører | _+_ | (det er en almindelig praksis for software at lokalisere sine ressourcefiler i forhold til sin egen placering).

Så den traditionelle måde at gøre det på er ved at bruge et symbolsk link:

-j

Dette er en enkel og effektiv løsning, især hvis en softwarepakke er lavet af kun få velkendte eksekverbare programmer-da du skal oprette et symbolsk link for hver kommando, der kan kaldes af brugeren. Hvis du f.eks. Kender NodeJS, kender du | _+_ | ledsagerapplikation Jeg skulle symlink fra | _+_ | også. Men det lod jeg dig som en øvelse.

Ændring af STIEN

For det første, hvis du prøvede den foregående løsning, skal du fjerne nodens symbolske link, der tidligere blev oprettet for at starte fra en klar tilstand:

sh$ make

Og nu er her den magiske kommando for at ændre din | _+_ |:

sh$ sudo make install

Kort sagt, jeg erstattede indholdet af | _+_ | miljøvariabel efter dets tidligere indhold, men præfikseret af | _+_ |. Så som du kan forestille dig det nu, vil skallen først kigge ind i | _+_ | bibliotek til eksekverbare programmer. Vi kan bekræfte, at ved hjælp af | _+_ | kommando:

fejlkode 43 mac kan ikke slette filen
sh$ /opt/node/bin/node --version v8.1.1

Mens linkløsningen er permanent, så snart du har oprettet det symbolske link til | _+_ |, er | _+_ | ændring er kun effektiv i den nuværende skal. Jeg lader dig undersøge, hvordan du foretager ændringer i | _+_ | permanent. Som et tip har det at gøre med din profil. Hvis du finder løsningen, tøv ikke med at dele det med de andre læsere ved at bruge kommentarfeltet herunder!

E. Sådan fjernes den nyinstallerede software fra kildekoden

Da vores specialkompilerede NodeJS -software sidder helt i | _+_ | mappe, fjernelse af denne software kræver ikke mere indsats end at bruge kommandoen rm til at fjerne det bibliotek:

[email protected] :~$ git clone --depth 1 --branch v8.1.1 https://github.com/nodejs/node -bash: git: command not found

PAS PÅ: | _+_ | og | _+_ | er en farlig cocktail! Kontroller altid din kommando to gange, før du trykker på enter -tasten. Du har ikke nogen bekræftelsesmeddelelse og ingen sletning, hvis du fjerner det forkerte bibliotek ...

Hvis du derefter har ændret din | _+_ |, bliver du nødt til at tilbagekalde disse ændringer, hvilket slet ikke er kompliceret.

Og hvis du har oprettet links fra | _+_ | du bliver nødt til at fjerne dem alle:

git

Vente? Hvor var afhængighedshelvede?

Som en sidste kommentar, hvis du læser om at kompilere din egen brugerdefinerede software, har du måske hørt om afhængighed helvede . Dette er et kaldenavn for den irriterende situation, hvor du, før du kan kompilere en software, først skal kompilere et påkrævet bibliotek, hvilket igen kræver et andet bibliotek, der igen kan være inkompatibelt med anden software, du allerede har installeret.

En del af pakkenes vedligeholdere af din distribution er faktisk at løse det afhængighedshelvede og sikre, at dit systems forskellige software bruger kompatible biblioteker og installeres i den rigtige rækkefølge.

Til denne artikel valgte jeg med vilje at installere NodeJS, da det stort set ikke har afhængigheder. Jeg sagde stort set fordi det faktisk var det har afhængigheder. Men kildekoden for disse afhængigheder er til stede i projektets kildeopbevaring (i undermappen | _+_ |), så du ikke behøver at downloade og installere dem manuelt før hånden.

Men hvis du er interesseret i at forstå mere om dette problem og lære at håndtere det, lad mig vide, at ved hjælp af kommentarfeltet herunder: det ville være et godt emne for en mere avanceret artikel!


Kan du lide hvad du læser? Del det gerne med andre.