Kort: denne detaljerte veiledningen forklarer Slik Installerer du Et program Fra Kildekoden I Linux Og hvordan du fjerner programvaren installert fra Kildekoden.

En av De største styrkene Til Linux-distribusjonen er pakkebehandleren og det tilhørende programvarelageret. Med dem har du alle nødvendige verktøy og ressurser for å laste ned og installere ny programvare på datamaskinen din på en helt automatisert måte.

men til tross for all sin innsats, kan pakkevedlikeholderne ikke håndtere hver brukstilfelle. De kan heller ikke pakke all programvare tilgjengelig der ute. Så det er fortsatt situasjoner der du må kompilere og installere ny programvare selv. For meg er den vanligste årsaken, langt, jeg må kompilere noe programvare, når jeg trenger å kjøre en veldig spesifikk versjon, eller endre kildekoden ved bruk av noen fancy kompileringsalternativer.

hvis dine behov tilhører sistnevnte kategori, er sjansen stor for at du allerede vet hva du skal gjøre. Men for De aller Fleste Linux-brukere kan kompilering og installering av programvare fra kildekoden for første gang se ut som en innvielsesseremoni: noe skremmende; men med løftet om å gå inn i en ny verden av muligheter og et prestisje i et privilegert samfunn.

A. Installere programvare fra kildekode I Linux

og det er akkurat det vi skal gjøre her. For formålet med denne artikkelen, la oss si at Jeg må installere NodeJS 8.1.1 på systemet mitt. Den versjonen nøyaktig. En versjon som Ikke er tilgjengelig fra Debian-depotet:

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

nå er det ganske enkelt å installere NodeJs På Ubuntu eller Debian hvis du gjør det med pakkebehandleren. Men la oss gjøre det via kildekoden.

Trinn 1: Få kildekoden fra GitHub

som mange åpen kildekode-prosjekter, kan Kildene Til NodeJS finnes på GitHub: https://github.com/nodejs/node

Så, la oss gå direkte dit.

hvis du ikke er kjent Med GitHub, git eller andre versjonskontrollsystem verdt å nevne depotet inneholder gjeldende kilde for programvaren, samt en historie av alle endringer gjort gjennom årene til at programvaren. Til slutt opp til den aller første linjen skrevet for det prosjektet. For utviklerne, holde at historien har mange fordeler. For oss i dag er det viktigste at vi vil kunne få kildene fra for prosjektet som de var på et gitt tidspunkt. Mer presist vil jeg kunne få kildene som de var da 8.1.1-versjonen jeg vil ha ble utgitt. Selv om det var mange modifikasjoner siden da.

På GitHub kan du bruke «branch» – knappen for å navigere mellom forskjellige versjoner av programvaren. «Branch » og» tags » er noe beslektede begreper I Git. I utgangspunktet lager utviklerne «gren» og «tags» for å holde oversikt over viktige hendelser i prosjektloggen, som når de begynner å jobbe med en ny funksjon eller når de publiserer en utgivelse. Jeg vil ikke gå inn i detaljene her, alt du trenger å vite er at jeg leter etter versjonen merket «v8.1.1»

etter a ha valgt pa «v8.1.1 » tag, siden oppdateres, den mest åpenbare endringen er taggen vises nå som en DEL av NETTADRESSEN. I tillegg vil du legge merke til at filendringsdatoen også er forskjellig. Kildetreet du ser nå, er det som eksisterte da v8.1.1-taggen ble opprettet. På en måte kan du tenke på et versjonskontrollverktøy som git som en tidsreisemaskin, slik at du kan gå frem og tilbake i en prosjekthistorie.

på dette punktet kan vi laste ned Kildene Til NodeJS 8.1.1. Du kan ikke gå glipp av den store blå knappen som tyder på å laste NED ZIP-arkivet til prosjektet. Når det gjelder meg, vil jeg laste NED OG trekke UT ZIP fra kommandolinjen for forklaringens skyld. Men hvis du foretrekker å bruke ET GUI-verktøy, ikke nøl med å gjøre det i stedet:

wget https://github.com/nodejs/node/archive/v8.1.1.zipunzip v8.1.1.zipcd node-8.1.1/

Nedlasting AV ZIP-arkivet fungerer bra. Men hvis du vil gjøre det «som en proff», vil jeg foreslå å bruke direktegit verktøy for å laste ned kildene. Det er ikke komplisert i det hele tatt – Og det vil være en fin første kontakt med et verktøy du ofte vil støte på:

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

forresten, hvis du har et problem, bare vurder den første delen av denne artikkelen som en generell introduksjon. Senere har jeg mer detaljerte forklaringer For Debian-og RedHat-baserte distribusjoner for å hjelpe deg med å feilsøke vanlige problemer.

uansett, når du lastet ned kilden ved hjelp av git eller som ET ZIP-arkiv, bør du nå ha nøyaktig de samme kildefilene i gjeldende katalog:

sh$ lsandroid-configure BUILDING.md common.gypi doc Makefile srcAUTHORS CHANGELOG.md configure GOVERNANCE.md node.gyp testbenchmark CODE_OF_CONDUCT.md CONTRIBUTING.md lib node.gypi toolsBSDmakefile COLLABORATOR_GUIDE.md deps LICENSE README.md vcbuild.bat

Trinn 2: Forstå Byggesystemet til programmet

vi snakker vanligvis om «kompilering av kildene», Men samlingen er bare en av fasene kreves for å produsere en fungerende programvare fra sin kilde. Et byggesystem er et sett med verktøy og praksis som brukes til å automatisere og artikulere de forskjellige oppgavene for å bygge helt programvaren bare ved å utstede få kommandoer.

hvis konseptet er enkelt, er virkeligheten noe mer komplisert. Fordi ulike prosjekter eller programmeringsspråk kan ha forskjellige krav. Eller på grunn av programmørens smak. Eller de støttede plattformene. Eller av historisk grunn. Eller … eller.. det er en nesten endeløs liste over grunner til å velge eller opprette et annet byggesystem. Alt som å si det er mange forskjellige løsninger som brukes der ute.NodeJS bruker EN GNU-stil bygge system, er det et populært valg i åpen kildekode-fellesskapet og igjen, en god måte å starte reisen.

Skriving og tuning av et byggesystem er en ganske kompleks oppgave, men FOR «sluttbrukeren», lette GNU-stilbyggesystemer oppgaven ved å bruke to verktøy: configureog make.

configure filen er et prosjektspesifikt skript som vil sjekke destinasjonssystemkonfigurasjonen og tilgjengelig funksjon for å sikre at prosjektet kan bygges, og til slutt håndtere spesifikasjonene til den nåværende plattformen.

en viktig del av en typiskconfigure jobb er å bygge Makefile. Det er filen som inneholder instruksjonene som kreves for å effektivt bygge prosjektet.

make verktøyet er DERIMOT ET POSIX-verktøy tilgjengelig på Ethvert Unix-lignende system. Det vil lese prosjektspesifikke Makefile og utføre de nødvendige operasjoner for å bygge og installere programmet.Men, som alltid I Linux-verdenen, har du fortsatt litt mildhet i å tilpasse bygningen til dine spesifikke behov.

./configure --help

kommandoenconfigure -help vil vise deg alle tilgjengelige konfigurasjonsalternativer. Igjen er dette veldig prosjektspesifikt. Og for å være ærlig, er det noen ganger nødvendig å grave inn i prosjektet før du fullt ut forstår betydningen av hvert konfigurasjonsalternativ.

Men det er minst ett STANDARD GNU Autotools-alternativ som du må vite: --prefix – alternativet. Dette har å gjøre med filsystemhierarkiet og stedet programvaren din vil bli installert.

Trinn 3: Fhs

Linux – filsystemhierarkiet på en typisk distribusjon overholder For det meste Filsystemhierarkistandarden (FHS)

denne standarden forklarer formålet med de ulike katalogene i systemet ditt: /usr/tmp/var og så videre.

når DU bruker GNU Autotools— OG de fleste andre byggesystemer— vil standard installasjonssted for den nye programvaren være /usr/local. Hvilket er et godt valg som I HENHOLD til FSH » / usr / local hierarchy er til bruk av systemadministratoren når du installerer programvare lokalt? Det må være trygt fra å bli overskrevet når systemprogramvaren er oppdatert. Den kan brukes til programmer og data som kan deles blant en gruppe verter, men ikke funnet i / usr.»

/usr/local hierarkiet liksom replikerer rotkatalogen, og du vil finne det/usr/local/bin for de kjørbare programmene,/usr/local/lib for bibliotekene,/usr/local/share for arkitektur uavhengige filer og så videre.på.Det eneste problemet når du bruker /usr/local tre for tilpasset programvareinstallasjon er filene for all programvaren din vil bli blandet der. Spesielt, etter å ha installert et par programvare, vil det være vanskelig å spore hvilken fil nøyaktig av /usr/local/bin og /usr/local/lib tilhører hvilken programvare. Det vil imidlertid ikke føre til noe problem for systemet. Tross alt er /usr/bin omtrent det samme rotet. Men det vil bli et problem dagen du vil fjerne en manuelt installert programvare.

for å løse dette problemet, foretrekker jeg vanligvis å installere tilpasset programvare i /opt sub-treet i stedet. Igjen, for å sitere FHS:

_ » / opt er reservert for installasjon av tilleggsprogramvarepakker.

en pakke som skal installeres i /opt må finne sine statiske filer i en egen /opt/<pakke> eller /opt/<leverandør> katalogtreet, hvor <pakke> er et navn som beskriver programvarepakken og <leverandør> er leverandørens lanana-registrerte navn.»_

Så vi vil lage en underkatalog av /opt spesielt for vår tilpassede NodeJS installasjon. Og hvis jeg en dag vil fjerne den programvaren, må jeg bare fjerne den katalogen:

sh$ sudo mkdir /opt/node-v8.1.1sh$ 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.1sh$ 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.

alt annet enn «ok» etter atmake kommandoen har fullført, ville bety at det var en feil under byggeprosessen. Da vi kjørte en parallell bygg på grunn av alternativet-j, er det ikke alltid lett å hente feilmeldingen gitt det store volumet av utgang produsert av byggesystemet.

i tilfelle et problem, bare start make, men uten-j denne gangen. Og feilen skal vises nær slutten av utgangen:

sh$ make

Til Slutt, når kompileringen har gått til slutten, kan Du installere programvaren til sin plassering ved å kjøre kommandoen:

sh$ sudo make install

og test den:

sh$ /opt/node/bin/node --versionv8.1.1

b. hva om ting går galt mens du installerer fra kildekoden?

det jeg har forklart ovenfor er for det meste hva du kan se på» build instruction » – siden av et veldokumentert prosjekt. Men gitt denne artikkelen målet er å la deg kompilere din første programvare fra kilder, kan det være verdt å ta deg tid til å undersøke noen vanlige problemer. Så, jeg vil gjøre hele prosedyren igjen, men denne gangen Fra et nytt Og minimalt Debian 9.0 og CentOS 7.0-systemer, slik at du kan se feilene jeg opplevde og hvordan jeg løste dem.

Fra Debian 9.0 «Stretch»

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

dette problemet er ganske enkelt å diagnostisere og løse. Bare installergit pakken:

:~$ sudo apt-get install git

:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

:~/node$ sudo mkdir /opt/node-v8.1.1:~/node$ sudo ln -sT node-v8.1.1 /opt/node

Ikke noe problem her.

:~/node$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

Åpenbart, for å kompilere et prosjekt, trenger du en kompilator. NodeJS blir skrevet med c++ – språket, vi trenger En c++ – kompilator. HER vil jeg installere `g++`, GNU C++ kompilatoren for det formålet:

:~/node$ sudo apt-get install g++:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

:~/node$ make -j9 && echo ok-bash: make: command not found

Et annet manglende verktøy. Samme symptomer. Samme løsning:

:~/node$ sudo apt-get install make:~/node$ make -j9 && echo okok

:~/node$ sudo make install:~/node$ /opt/node/bin/node --versionv8.1.1

Suksess!

vennligst legg merke Til: Jeg har installert de ulike verktøyene en etter en for å vise hvordan du diagnostiserer kompileringsproblemene og viser deg den typiske løsningen for å løse disse problemene. Men hvis du søker etter mer informasjon om emnet eller leser andre opplæringsprogrammer, vil du oppdage at de fleste distribusjoner har «meta-pakker» som fungerer som en paraply for å installere noen eller alle de typiske verktøyene som brukes til å kompilere en programvare. På Debian-baserte systemer vil du sannsynligvis møte build-essentials-pakken for det formålet. Og På Red-Hat-baserte distribusjoner, vil det være «Utviklingsverktøy» – gruppen.

Fra CentOS 7.0

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

Kommando ikke funnet? Bare installer den ved hjelp av yum pakkebehandling:

 ~]$ sudo yum install git

 ~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

 ~]$ sudo mkdir /opt/node-v8.1.1 ~]$ sudo ln -sT node-v8.1.1 /opt/node

 ~]$ cd node node]$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

du gjetter det: nodejs er skrevet med c++ – språket, men systemet mitt mangler den tilsvarende kompilatoren. Yum til unnsetning. Siden Jeg ikke er en vanlig CentOS-bruker, måtte jeg faktisk søke på Internett det eksakte navnet på pakken som inneholder g++ – kompilatoren. Fører meg til den siden: https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

 node]$ sudo yum install gcc-c++ node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

 node]$ make -j9 && echo okok

 node]$ sudo make install && echo okok

 node]$ /opt/node/bin/node --versionv8.1.1

Suksess. Atter.

C. Å gjøre endringer i programvaren installert fra kildekoden

du kan installere programvare fra kilden fordi du trenger en veldig spesifikk versjon som ikke er tilgjengelig i distribusjonsregisteret ditt, eller fordi du vil endre programmet for å fikse en feil eller legge til en funksjon. Tross alt handler open source om å gjøre endringer. Så, jeg vil benytte anledningen til å gi deg en smak av kraften du har for hånden nå som du er i stand til å kompilere din egen programvare.

Her vil vi gjøre en mindre endring i Kildene Til NodeJS. Og vi vil se om vår endring vil bli innlemmet i den kompilerte versjonen av programvaren:

Åpne filennode/src/node.cc i din favoritt tekstredigerer (vim, nano, gedit,…). Og prøv å finne det fragmentet av kode:

 if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) { printf("%s\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp(); exit(0); }

det er rundt linje 3830 av filen. Endre deretter linjen som inneholder printf for å matche den i stedet:

 printf("%s (compiled by myself)\n", NODE_VERSION);

deretter hodet tilbake til terminalen. Før du går videre— og for å gi deg litt mer innsikt i kraften bak git – kan du sjekke om du har endret riktig fil:

diff --git a/src/node.cc b/src/node.ccindex bbce1022..a5618b57 100644--- a/src/node.cc+++ b/src/node.cc@@ -3828,7 +3828,7 @@ static void ParseArgs(int* argc, if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) {- printf("%s\n", NODE_VERSION);+ printf("%s (compiled by myself)\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp();

du bør se et » – » (minustegn) før linjen som den var før du endret den. Og et » + » (plusstegn) før linjen etter endringene dine.

det er nå på tide å kompilere og installere programvaren på nytt:

make -j9 && sudo make install && echo okok

Denne gangen er den eneste grunnen til at det kan mislykkes, at du har gjort en skrivefeil mens du endret koden. Hvis dette er tilfelle, åpner du node/src/node.cc – filen i tekstredigeringsprogrammet og løser feilen.

Når du har klart å kompilere og installere Den nye modifiserte NodeJS-versjonen, vil du kunne sjekke om endringene dine faktisk ble innlemmet i programvaren:

:~/node$ /opt/node/bin/node --versionv8.1.1 (compiled by myself)

Gratulerer! Du har gjort din første endring til en åpen kildekode-program!

D. La skallet finne vår tilpassede byggeprogramvare

Du har kanskje lagt merke til at Jeg alltid har lansert Min nylig kompilerte NodeJS-programvare ved å angi den absolutte banen til binærfilen.

/opt/node/bin/node

det fungerer. Men dette er irriterende, minst sagt. Det er faktisk to vanlige måter å fikse det på.Det er faktisk to vanlige måter å fikse det irriterende problemet med å spesifisere den absolutte banen til de binære filene, men for å forstå dem må du først vite at skallet ditt lokaliserer de kjørbare filene ved å lete etter dem bare i katalogene spesifisert av PATH-miljøvariabelen.

:~/node$ echo $PATH/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Her, på Det Debian-systemet, Hvis du ikke spesifiserer eksplisitt noen katalog som en del av et kommandonavn, vil skallet først se etter de kjørbare programmene i /usr/local/bin, så hvis ikke funnet i /usr/bin, så hvis ikke funnet i /bin så hvis ikke funnet i /usr/local/games så hvis ikke funnet i /usr/games, så hvis ikke funnet … vil skallet rapportere en feil «kommando ikke funnet».

Gitt at vi har to måter å gjøre en kommando tilgjengelig for skallet: ved å legge den til en av de allerede konfigurerte PATH kataloger. Eller ved å legge til katalogen som inneholder vår kjørbare fil til PATH.

Å Legge til en lenke fra /usr/local/bin

bare kopiere noden binær kjørbar fra /opt/node/bin til /usr/local/bin ville være en dårlig ide siden det kjørbare programmet ikke lenger kunne finne de andre nødvendige komponentene som tilhører /opt/node/ (Det er en vanlig praksis For Programvare å finne ressursfilene i forhold til sin egen plassering).

så den tradisjonelle måten å gjøre det på er å bruke en symbolsk lenke:

:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node:~/node$ which -a node || echo not found/usr/local/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

Dette er en enkel og effektiv løsning, spesielt hvis en programvarepakke er laget av bare noen få kjente kjørbare programmer-siden du må lage en symbolsk lenke for hver bruker-invokable kommando. For eksempel, hvis du er kjent Med NodeJS, vet du npm companion program jeg skal symlink fra /usr/local/bin også. Men jeg la det til deg som en øvelse.

Endre BANEN

først, hvis du prøvde den forrige løsningen, fjern node symbolsk lenke opprettet tidligere for å starte fra en klar tilstand:

:~/node$ sudo rm /usr/local/bin/node:~/node$ which -a node || echo not foundnot found

Og nå, her er den magiske kommandoen for å endre PATH:

:~/node$ export PATH="/opt/node/bin:${PATH}":~/node$ echo $PATH/opt/node/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

bare sagt, jeg erstattet innholdet i PATH miljøvariabelen med sitt tidligere innhold, men prefiks av /opt/node/bin. Så, som du kan forestille deg det nå, vil skallet først se på/opt/node/bin katalog for kjørbare programmer. Vi kan bekrefte at du bruker kommandoen which:

:~/node$ which -a node || echo not found/opt/node/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

mens «link» – løsningen er permanent så snart du har opprettet den symbolske lenken til/usr/local/binPATHendre er kun effektiv i det nåværende skallet. Jeg vil la deg gjøre noen undersøkelser om hvordan du gjør endringer iPATHpermanents. Som et hint har det å gjøre med din «profil». Hvis du finner løsningen, ikke nøl med å dele det med de andre leserne ved å bruke kommentarfeltet nedenfor!

E. Slik fjerner du den nylig installerte programvaren fra kildekoden

siden Vår tilpassede kompilerte NodeJS-programvare sitter helt i katalogen /opt/node-v8.1.1 fjerning av programvaren krever ikke mer innsats enn å bruke rm-kommandoen for å fjerne den katalogen:

sudo rm -rf /opt/node-v8.1.1

PASS på: sudo og rm -rf Er en farlig cocktail! Kontroller alltid kommandoen to ganger før du trykker på» enter » – tasten. Du vil ikke ha noen bekreftelsesmelding og ingen angre hvis du fjerner feil katalog …

Så, hvis du har endret din PATH, må du tilbakestille disse endringene, noe som ikke er komplisert i det hele tatt.

Og hvis du har opprettet lenker fra /usr/local/bin må du fjerne dem alle:

:~/node$ sudo find /usr/local/bin \ -type l \ -ilname "/opt/node/*" \ -print -delete/usr/local/bin/node

Vent? Hvor Var Avhengigheten Helvete?

som en sluttkommentar, hvis du leser om å samle din egen tilpassede programvare, har du kanskje hørt om dependency hell. Dette er et kallenavn for den irriterende situasjonen der før du kan kompilere en programvare, må du først kompilere et nødvendig bibliotek, som i sin tur krever et annet bibliotek som i sin tur kan være uforenlig med annen programvare du allerede har installert.

En del av jobben til pakkevedlikeholderne i distribusjonen din er å faktisk løse det avhengighetshelvete og for å sikre at de forskjellige programmene i systemet ditt bruker kompatible biblioteker og er installert i riktig rekkefølge.

for denne artikkelen valgte jeg med vilje å installere NodeJS da det nesten ikke har avhengigheter. Jeg sa «nesten» fordi det faktisk har avhengigheter. Men kildekoden til disse avhengighetene er til stede i kildelageret til prosjektet (i node/deps underkatalog), så du trenger ikke å laste ned og installere dem manuelt før hånd.