kort: Den här detaljerade guiden förklarar hur man installerar ett program från källkod i Linux och hur man tar bort programvaran installerad från källkoden.

en av de största styrkan i din Linux-distribution är dess pakethanterare och tillhörande programvaruförvar. Med dem har du alla nödvändiga verktyg och resurser för att ladda ner och installera ny programvara på din dator på ett helt automatiserat sätt.

men trots alla sina ansträngningar kan paketansvariga inte hantera varje användningsfall. Inte heller kan de paketera all programvara som finns där ute. Så det finns fortfarande situationer där du måste kompilera och installera ny programvara själv. När det gäller mig är den vanligaste orsaken, överlägset, att jag måste kompilera någon programvara när jag behöver köra en mycket specifik version eller ändra källkoden med hjälp av några fina kompileringsalternativ.

om dina behov tillhör den senare kategorin är chansen att du redan vet vad du ska göra. Men för de allra flesta Linux-användare kan kompilering och installation av programvara från källkoden för första gången se ut som en initieringsceremoni: något skrämmande; men med löftet att komma in i en ny värld av möjligheter och en plats för prestige i ett privilegierat samhälle.

A. installera programvara från källkod i Linux

och det är precis vad vi ska göra här. För den här artikeln, låt oss säga att jag måste installera NodeJS 8.1.1 på mitt system. Den versionen exakt. En version som inte är tillgänglig från Debianförvaret:

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 är det ganska enkelt att installera NodeJs på Ubuntu eller Debian om du gör det med pakethanteraren. Men låt oss göra det via källkoden.

Steg 1: hämta källkoden från GitHub

liksom många open source-projekt kan källorna till NodeJS hittas på GitHub:https://github.com/nodejs/node

Så, låt oss gå direkt dit.

om du inte är bekant med GitHub, git eller något annat versionskontrollsystem som är värt att nämna förvaret innehåller den aktuella källan för Programvaran, samt en historik av alla ändringar som gjorts genom åren till den programvaran. Så småningom upp till den allra första raden skriven för det projektet. För utvecklarna, att hålla den historien har många fördelar. För oss idag är det viktigaste att vi kommer att kunna få källorna till projektet som de var vid varje given tidpunkt. Mer exakt kommer jag att kunna få källorna som de var när 8.1.1-versionen Jag vill ha släpptes. Även om det fanns många modifieringar sedan dess.

på GitHub kan du använda ”branch” – knappen för att navigera mellan olika versioner av programvaran. ”Branch” och ”tags” är något relaterade begrepp i Git. I grund och botten skapar utvecklarna ”branch” och ”tags” för att hålla reda på viktiga händelser i projekthistoriken, som när de börjar arbeta med en ny funktion eller när de publicerar en release. Jag kommer inte att gå in på detaljerna här, Allt du behöver veta är att jag letar efter versionen taggad ”v8.1.1”

Efter att ha valt på ”V8.1.1 ” tag, sidan uppdateras, den mest uppenbara förändringen är taggen visas nu som en del av webbadressen. Dessutom kommer du att märka att filändringsdatumet också är annorlunda. Källträdet du nu ser är det som fanns vid den tidpunkt då V8.1. 1-taggen skapades. På något sätt kan du tänka på ett versionskontrollverktyg som git som en tidsresemaskin, så att du kan gå fram och tillbaka till en projekthistoria.

vid denna punkt kan vi ladda ner källorna till NodeJS 8.1.1. Du kan inte missa den stora blå knappen som föreslår att du laddar ner projektets ZIP-arkiv. När det gäller mig kommer jag att ladda ner och extrahera ZIP från kommandoraden för förklaringens skull. Men om du föredrar att använda ett GUI-verktyg, tveka inte att göra det istället:

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

nedladdning av ZIP-arkivet fungerar bra. Men om du vill göra det ”som ett proffs”, skulle jag föreslå att du använder verktyget git för att ladda ner källorna. Det är inte komplicerat alls-och det blir en trevlig första kontakt med ett verktyg som du ofta kommer att stöta 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/

förresten, om du har ett problem, överväga bara den första delen av den här artikeln som en allmän introduktion. Senare har jag mer detaljerade förklaringar till Debian – och RedHat-baserade distributioner för att hjälpa dig att felsöka vanliga problem.

hur som helst, när du laddade ner källan med git eller som ett ZIP-arkiv, bör du nu ha exakt samma källfiler i den aktuella katalogen:

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

steg 2: förstå programmets byggsystem

Vi brukar prata om ”sammanställa källorna”, men kompileringen är bara en av faserna krävs för att producera en fungerande programvara från källan. Ett byggsystem är en uppsättning verktyg och metoder som används för att automatisera och formulera dessa olika uppgifter för att bygga helt programvaran bara genom att utfärda några kommandon.

om konceptet är enkelt är verkligheten något mer komplicerad. Eftersom olika projekt eller programmeringsspråk kan ha olika krav. Eller på grund av programmerarens smak. Eller de plattformar som stöds. Eller av historiska skäl. Eller … eller.. det finns en nästan oändlig lista med skäl att välja eller skapa ett annat byggsystem. Allt detta för att säga att det finns många olika lösningar som används där ute.

NodeJS använder ett byggsystem i GNU-stil, det är ett populärt val i Open source-communityn och återigen ett bra sätt att börja din resa.att skriva och ställa in ett byggsystem är en ganska komplex uppgift, men för ”slutanvändaren”underlättar GNU-stilbyggnadssystem uppgiften genom att använda två verktyg: configure och make.

configure-filen är ett projektspecifikt skript som kontrollerar destinationssystemets konfiguration och tillgängliga funktion för att säkerställa att projektet kan byggas, så småningom hantera specifikationerna för den aktuella plattformen.

en viktig del av en typiskconfigure jobb är att byggaMakefile. Det är filen som innehåller de instruktioner som krävs för att effektivt bygga projektet.

make – verktyget är å andra sidan ett POSIX-verktyg tillgängligt på alla Unix-liknande system. Det kommer att läsa projektspecifika Makefile och utföra de åtgärder som krävs för att bygga och installera programmet.

men som alltid i Linux-världen har du fortfarande en viss förmånlighet när du anpassar byggnaden efter dina specifika behov.

./configure --help

kommandotconfigure -help visar alla tillgängliga konfigurationsalternativ. Återigen är detta mycket projektspecifikt. Och för att vara ärlig är det ibland nödvändigt att gräva in i projektet innan man helt förstår betydelsen av varje konfigurationsalternativ.

men det finns minst ett standard GNU Autotools-alternativ som du måste känna till: alternativet --prefix. Detta har att göra med filsystemhierarkin och platsen din programvara kommer att installeras.

steg 3: FHS

Linux-filsystemhierarkin på en typisk distribution överensstämmer mestadels med Filsystemhierarkistandarden (FHS)

den standarden förklarar syftet med de olika katalogerna i ditt system:/usr/tmp/var och så vidare.

När du använder GNU Autotools— och de flesta andra byggsystem— kommer standardinstallationsplatsen för din nya programvara att vara /usr/local. Vilket är ett bra val som enligt FSH ” den/usr / lokala hierarkin är för användning av systemadministratören när du installerar programvara lokalt? Det måste vara säkert från att skrivas över när systemprogramvaran uppdateras. Den kan användas för program och data som kan delas mellan en grupp värdar, men som inte finns i /usr.”

/usr/local hierarkin replikerar på något sätt rotkatalogen, och du hittar där /usr/local/bin för de körbara programmen, /usr/local/lib för biblioteken, /usr/local/share för arkitekturoberoende filer och så vidare.

det enda problemet när du använder/usr/local träd för anpassad programinstallation är filerna för all din programvara kommer att blandas där. Speciellt, efter att ha installerat ett par program, blir det svårt att spåra till vilken fil exakt av /usr/local/bin och /usr/local/lib tillhör vilken programvara. Det kommer dock inte att orsaka några problem för systemet. När allt kommer omkring är /usr/bin ungefär samma röra. Men det blir ett problem den dagen du vill ta bort en manuellt installerad programvara.

för att lösa problemet föredrar jag vanligtvis att installera anpassad programvara i /opt underträd istället. Återigen, för att citera FHS:

_” / opt är reserverat för installation av tilläggsprogramvarupaket.

ett paket som ska installeras i /opt måste hitta sina statiska filer i ett separat /opt/<paket> eller /opt/<provider> katalogträd, där<paket> är ett namn som beskriver mjukvarupaketet och<provider> är leverantörens lanana-registrerade namn.”_

Så vi skapar en underkatalog med /opt speciellt för vår anpassade NodeJS-installation. Och om jag en dag vill ta bort den programvaran måste jag helt enkelt ta bort 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.

allt annat än ”ok” efter att make kommandot har slutförts skulle innebära att det fanns ett fel under byggprocessen. När vi körde en parallell byggnad på grund av alternativet -j är det inte alltid lätt att hämta felmeddelandet med tanke på den stora volymen av produktionen som produceras av byggsystemet.

i händelse av ett problem, starta bara ommake, men utan-j alternativet den här gången. Och felet ska visas nära slutet av utgången:

sh$ make

slutligen, när kompileringen har gått till slutet, kan du installera din programvara till dess plats genom att köra kommandot:

sh$ sudo make install

och testa det:

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

B. Vad händer om saker går fel när du installerar från källkod?

vad jag har förklarat ovan är mestadels vad du kan se på sidan” bygginstruktion ” i ett väldokumenterat projekt. Men med tanke på denna artikel mål är att låta dig sammanställa din första programvara från källor, kan det värt att ta sig tid att undersöka några vanliga frågor. Så jag kommer att göra hela proceduren igen, men den här gången från ett nytt och minimalt Debian 9.0-och CentOS 7.0-system så att du kan se de fel jag stött på och hur jag löste dem.

från Debian 9.0 ”Stretch”

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

detta problem är ganska lätt att diagnostisera och lösa. Installera baragit paketet:

:~$ 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

inga problem här.

:~/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.

självklart behöver du en kompilator för att sammanställa ett projekt. NodeJS skrivs med C++ – språket, vi behöver en C++ – kompilator. Här installerar jag ’ g++’, GNU C++ – kompilatorn för det ändamå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

ett annat saknat verktyg. Samma symptom. Samma 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

framgång!

Vänligen notera: Jag har installerat de olika verktygen en efter en för att visa hur man diagnostiserar kompileringsproblemen och för att visa dig den typiska lösningen för att lösa dessa problem. Men om du söker efter mer information om ämnet eller läser andra handledning kommer du att upptäcka att de flesta distributioner har ”meta-paket” som fungerar som ett paraply för att installera några eller alla typiska verktyg som används för att sammanställa en programvara. På Debianbaserade system kommer du förmodligen att stöta på build-essentials-paketet för det ändamålet. Och på Red-Hat – baserade distributioner kommer det att vara gruppen” utvecklingsverktyg”.

från CentOS 7.0

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

kommandot hittades inte? Installera det bara med yum pakethanteraren:

 ~]$ 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 antar det: NodeJS är skrivet med C++ – språket, men mitt system saknar motsvarande kompilator. Yum till undsättning. Eftersom jag inte är en vanlig CentOS-användare, var jag faktiskt tvungen att söka på Internet det exakta namnet på paketet som innehåller g++ – kompilatorn. Leder mig till den sidan: 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

framgång. Igen.

C. göra ändringar i programvaran installerad från källkod

Du kan installera programvara från källan eftersom du behöver en mycket specifik version som inte är tillgänglig i ditt distributionsförvar, eller för att du vill ändra programmet för att åtgärda ett fel eller lägga till en funktion. När allt kommer omkring handlar öppen källkod om att göra ändringar. Så jag kommer att ta tillfället i akt för att ge dig en smak av den kraft du har till hands nu när du kan sammanställa din egen programvara.

Här kommer vi att göra en mindre ändring av källorna till NodeJS. Och vi kommer att se om vår ändring kommer att införlivas i den kompilerade versionen av programvaran:

öppna filen node/src/node.cc I din favorittextredigerare (vim, nano, gedit, … ). Och försök att hitta det fragmentet av kod:

 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 är runt rad 3830 i filen. Ändra sedan raden som innehåller printf för att matcha den istället:

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

gå sedan tillbaka till din terminal. Innan du går vidare— och för att ge dig lite mer inblick i kraften bakom git-kan du kontrollera om du har ändrat rätt 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 ett ” – ” (minustecken) före raden som det var innan du ändrade det. Och ett ” + ” (plustecken) före raden efter dina ändringar.

det är nu dags att kompilera om och installera om din programvara:

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

den här gången är den enda anledningen till att det kan misslyckas att du har gjort ett stavfel när du ändrar koden. Om så är fallet, öppna filen node/src/node.cc I din textredigerare och åtgärda felet.

När du har lyckats kompilera och installera den nya modifierade NodeJS-versionen kan du kontrollera om dina ändringar faktiskt införlivades i programvaran:

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

Grattis! Du har gjort din första ändring till ett open source-program!

D. låt skalet hitta vår anpassade byggprogramvara

Du kanske har märkt att jag alltid har lanserat min nyligen kompilerade NodeJS-programvara genom att ange den absoluta sökvägen till binärfilen.

/opt/node/bin/node

det fungerar. Men det här är minst sagt irriterande. Det finns faktiskt två vanliga sätt att fixa det.

det finns faktiskt två vanliga sätt att fixa det irriterande problemet med att ange den absoluta sökvägen till de binära filerna, men för att förstå dem måste du först veta att ditt skal lokaliserar de körbara filerna genom att bara leta efter dem i katalogerna som anges av path-miljövariabeln.

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

här, på det Debiansystemet, om du inte uttryckligen anger någon katalog som en del av ett kommandonamn, kommer skalet först att leta efter de körbara programmen i /usr/local/bin, om det inte hittas i /usr/bin, om det inte hittas i /bin om det inte hittades i /usr/local/games om det inte hittades i /usr/games, då om det inte hittades … kommer skalet att rapportera ett fel ”kommandot hittades inte”.

Med tanke på att vi har två sätt att göra ett kommando tillgängligt för skalet: genom att lägga till den i en av de redan konfigurerade PATH kataloger. Eller genom att lägga till katalogen som innehåller vår körbara fil till PATH.

att lägga till en länk från /usr/local/bin

bara kopiera noden binär körbar från /opt/node/bin till /usr/local/bin skulle vara en dålig ide eftersom det körbara programmet inte längre skulle kunna hitta de andra nödvändiga komponenterna som tillhör /opt/node/ (det är en vanlig praxis för programvara att hitta sina resursfiler i förhållande till sin egen plats).

så det traditionella sättet att göra det är att använda en symbolisk länk:

:~/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)

detta är en enkel och effektiv lösning, särskilt om ett mjukvarupaket består av bara några välkända körbara program— eftersom du måste skapa en symbolisk länk för varje användarinokabel kommando. Om du till exempel är bekant med NodeJS känner du till npm companion application jag ska symbolisera från /usr/local/bin också. Men jag låter det till dig som en övning.

ändra sökvägen

först, om du försökte föregående lösning, ta bort nodens symboliska länk som skapats tidigare för att starta från ett tydligt tillstånd:

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

och nu är det magiska kommandot för att ändra dittPATH:

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

enkelt sagt, Jag ersatte innehållet iPATH miljövariabel med dess tidigare innehåll, men prefixet med/opt/node/bin. Så, som du kan föreställa dig det nu, kommer skalet att se först in i katalogen /opt/node/bin för körbara program. Vi kan bekräfta att du använder kommandot which:

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

medan ”link” – lösningen är permanent så snart du har skapat den symboliska länken till /usr/local/binPATH ändra är endast effektiv i det aktuella skalet. Jag kommer att lämna dig att göra lite forskning om hur man gör ändringar i PATH permanents. Som en ledtråd, Det har att göra med din ”profil”. Om du hittar lösningen, tveka inte att dela den med de andra läsarna genom att använda kommentarsektionen nedan!

E. Så här tar du bort den nyinstallerade Programvaran från källkoden

eftersom vår anpassade kompilerade NodeJS-programvara sitter helt i katalogen /opt/node-v8.1.1, tar du bort den programvaran inte mer ansträngning än att använda RM-kommandot för att ta bort den katalogen:

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

akta dig: sudo och rm -rf är en farlig cocktail! Kontrollera alltid ditt kommando två gånger innan du trycker på ”enter” – tangenten. Du kommer inte att ha något bekräftelsemeddelande och ingen återställning om du tar bort fel katalog…

sedan, om du har ändrat din PATH, måste du återställa dessa ändringar, vilket inte är komplicerat alls.

och om du har skapat länkar från /usr/local/bin måste du ta bort dem alla:

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

vänta? Var var beroendet helvetet?

som en sista kommentar, om du läser om att sammanställa din egen anpassade programvara, kanske du har hört talas om beroendet helvetet. Detta är ett smeknamn för den irriterande situationen där innan du lyckas kompilera en programvara måste du först kompilera ett nödvändigt bibliotek, vilket i sin tur kräver ett annat bibliotek som i sin tur kan vara oförenligt med någon annan programvara du redan har installerat.

en del av jobbet för paketansvariga för din distribution är att faktiskt lösa det beroende helvetet och för att säkerställa att olika programvaror i ditt system använder kompatibla bibliotek och installeras i rätt ordning.

För den här artikeln valde jag med avsikt att installera NodeJS eftersom det praktiskt taget inte har beroenden. Jag sa ”praktiskt taget” eftersom det faktiskt har beroenden. Men källkoden för dessa beroenden finns i projektets källförvar (i underkatalogen node/deps), så du behöver inte ladda ner och installera dem manuellt före hand.