Как да инсталирате софтуера от изходния код ... и го премахнете след това

Кратко: Това подробно ръководство обяснява как да инсталирате програма от изходния код в Linux и как да премахнете инсталирания софтуер от изходния код.

Една от най-големите предимства на вашата Linux дистрибуция е нейният мениджър на пакети и свързания с него репозиториев софтуер. С тях разполагате с всички необходими инструменти и ресурси, за да изтеглите и инсталирате нов софтуер на вашия компютър по напълно автоматизиран начин.

Но въпреки всичките им усилия, поддръжниците на пакети не могат да се справят с всеки случай на употреба. Нито пък могат да пакетират целия наличен софтуер. Така че все още има ситуации, в които ще трябва сами да съставяте и инсталирате нов софтуер. От себе си, най-често срещаната причина, досега, трябва да компилирам някакъв софтуер, когато трябва да стартирам много специфична версия. Или защото искам да променям изходния код или да използвам някои фантастични опции за компилация.

Ако вашите нужди принадлежат към последната категория, има шанс вече да знаете какво правите. Но за по-голямата част от потребителите на Linux, компилирането и инсталирането на софтуер от източниците за първи път може да изглежда като церемония по иницииране: донякъде плашеща; но с обещанието да влезеш в нов свят от възможности и да бъдеш част от привилегированата общност, ако преодолееш това.

A. Инсталиране на софтуер от изходния код в Linux

И точно това ще направим тук. За целта на тази статия, нека кажем, че трябва да инсталирам NodeJS 8.1.1 на моята система. Тази версия точно. Версия, която не е налична в хранилището на Дебиан:

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

Сега инсталирането на NodeJs в Ubuntu или Debian е доста просто, ако го направите с мениджъра на пакети. Но нека го направим чрез изходния код.

Стъпка 1: Получаване на изходния код от GitHub

Подобно на много проекти с отворен код, източниците на NodeJS могат да бъдат намерени на GitHub: //github.com/nodejs/node

Така че, нека отидем направо там.

Ако не сте запознати с GitHub, git или всяка друга система за контрол на версиите, която трябва да споменете, хранилището съдържа текущия източник на софтуера, както и история на всички модификации, направени през годините на този софтуер. В крайна сметка до първата линия, написана за този проект. За разработчиците, запазването на тази история има много предимства. За нас днес основното е, че ще можем да получим източниците от проекта, както са били в даден момент. По-точно, ще мога да получа източниците, каквито са били, когато версия 8.1.1, която искам, беше освободена. Дори и след това да има много модификации.

В GitHub можете да използвате бутона "branch" за навигиране между различните версии на софтуера. "Бранш" и "тагове" са донякъде свързани понятия в Git. По принцип, разработчиците създават "клон" и "тагове", за да следят важни събития в историята на проекта, като например, когато започнат да работят върху нова функция или когато публикуват съобщение. Няма да се занимавам с подробности тук, всичко, което трябва да знаете е, че търся версията с надпис „v8.1.1“

След като сте избрали етикет “v8.1.1”, страницата се обновява, като най-очевидната промяна е, че маркерът сега се появява като част от URL адреса. Освен това ще забележите, че датата на промяна на файла също е различна. Дървото на източника, което виждате сега, е това, което съществуваше по време на създаването на маркера v8.1.1. В известен смисъл, можете да се сетите за инструмент за контрол на версиите като git като машина за пътуване във времето, която ви позволява да се върнете назад и напред в историята на проекта.

На този етап можем да изтеглим източниците на NodeJS 8.1.1. Не можете да пропуснете големия син бутон, предлагащ да изтеглите ZIP архива на проекта. От себе си ще изтегля и извлече ZIP от командния ред заради обяснението. Но ако предпочитате да използвате инструмент с графичен потребителски интерфейс, не се колебайте да го направите вместо това:

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

Изтеглянето на ZIP архива работи чудесно. Но ако искате да го направите „като професионалист“, бих предложил директно да използвате инструмента git за да изтеглите източниците. Той изобщо не е сложен - и това ще бъде добър първи контакт с инструмент, с който често се сблъсквате:

 # 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 \ //github.com/nodejs/node sh$ cd node/ 

Между другото, ако имате някакъв проблем, просто помислете за първата част на тази статия като общо въведение. По-късно имам по-подробни обяснения за дистрибуциите, базирани на Debian и RedHat, за да ви помогна да отстранявате често срещани проблеми.

Както и да е, всеки път, когато сте изтеглили източника, използвайки git или като ZIP архив, сега трябва да имате точно същите изходни файлове в текущата директория:

 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 

Стъпка 2: Разбиране на системата за изграждане на програмата

Обикновено говорим за „компилиране на източниците“, но компилацията е само една от фазите, необходими за създаването на работещ софтуер от неговия източник. Система за изграждане е набор от инструменти и практики, използвани за автоматизиране и артикулиране на тези различни задачи, за да се изгради изцяло софтуера само чрез издаване на няколко команди.

Ако концепцията е проста, реалността е малко по-сложна. Защото различни проекти или език за програмиране могат да имат различни изисквания. Или поради вкуса на програмиста. Или поддържаните платформи. Или по исторически причини. Или… или .. има почти безкраен списък от причини да изберете или създадете друга система за изграждане. Всичко това, за да се каже, че там има много различни решения.

NodeJS използва система за изграждане на стил GNU. Това е популярен избор в общността с отворен код. И още веднъж, добър начин да започнете пътуването си.

Писането и настройката на система за изграждане е доста сложна задача. Но за „крайния потребител“, системите за изграждане на стил GNU се възобновяват при използването на два инструмента: configure и make .

configure файл е специфичен за проекта скрипт, който ще проверява конфигурацията на системата на дестинацията и наличната функция, за да гарантира, че проектът може да бъде изграден, и в крайна сметка да се справя със спецификите на текущата платформа.

Важна част от типично задание за configure е да се създаде Makefile . Това е файлът, съдържащ инструкциите, необходими за ефективно изграждане на проекта.

Инструментът make, от друга страна, е POSIX инструмент, наличен във всяка Unix-подобна система. Той ще прочете специфичния за проекта Makefile и ще изпълни необходимите операции за изграждане и инсталиране на вашата програма.

Но, както винаги в света на Linux, все още имате известно забавяне, за да персонализирате конструкцията за вашите специфични нужди.

 ./configure --help 

Командата configure -help ще ви покаже всички налични опции за конфигурация. Още веднъж, това е много специфично за проекта. И за да бъдем честни, понякога е необходимо да копаем в проекта, преди напълно да разберем значението на всяка опция за конфигуриране.

Но има поне една стандартна опция за GNU Autotools, която трябва да знаете: опцията --prefix . Това е свързано с йерархията на файловата система и мястото, където ще бъде инсталиран вашият софтуер.

Стъпка 3: FHS

Йерархията на файловата система на Linux в типично разпределение най-вече отговаря на стандарта за йерархия на файловата система (FHS)

Този стандарт обяснява целта на различните директории на вашата система: /usr, /tmp, /var и т.н.

Когато използвате GNU Autotools - и повечето други системи за изграждане - мястото за инсталиране по подразбиране за вашия нов софтуер ще бъде /usr/local . Кой е добър избор, според FSH “Йерархията / usr / local е за използване от системния администратор при локално инсталиране на софтуер? Необходимо е да бъде безопасно да не бъде презаписано, когато системният софтуер бъде актуализиран. Може да се използва за програми и данни, които са споделени между група хостове, но не се намират в / usr. "

Йерархията /usr/local по някакъв начин репликира основната директория и ще намерите там /usr/local/bin за изпълними програми, /usr/local/lib за библиотеките, /usr/local/share за архитектурни независими файлове и т.н. нататък.

Единственият проблем при използването на /usr/local tree за инсталиране на софтуер по избор е, че файловете за целия ви софтуер ще бъдат смесени там. Особено, след като сте инсталирали няколко софтуера, ще бъде трудно да се проследи до кой файл точно от /usr/local/bin и /usr/local/lib принадлежи към кой софтуер. Това обаче няма да предизвика проблем в системата. В крайна сметка, /usr/bin е почти същата бъркотия. Но това ще стане проблем в деня, в който ще искате да премахнете ръчно инсталиран софтуер.

За да решим този проблем, обикновено предпочитам да инсталирам потребителски софтуер в под-дървото /opt . Още веднъж, за да цитирам FHS:

_ ”/ Opt е запазено за инсталирането на допълнителни софтуерни пакети за приложения.

Пакетът, който ще се инсталира в / opt, трябва да открие статичните му файлове в отделно / opt / или / opt / директория, където е името, което описва софтуерния пакет и е LANANA регистрирано име на доставчика.

Така че ние ще създадем поддиректория на /opt специално за нашата потребителска инсталация на NodeJS. И ако някой ден искам да премахна този софтуер, просто ще трябва да премахна тази директория:

 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. 

Всичко, освен “ОК” след завършване на командата make би означавало, че е имало грешка по време на процеса на изграждане. Тъй като ние стартирахме паралелно изграждане поради опцията -j, не винаги е лесно да изтеглите съобщението за грешка, като се има предвид големият обем продукция, произведена от системата за изграждане.

В случай на издаване, просто рестартирайте make, но без опцията -j този път. А грешката трябва да се появи в края на изхода:

 sh$ make 

И накрая, след като компилацията приключи, можете да инсталирате софтуера на неговото местоположение, като изпълните командата:

 sh$ sudo make install 

И го тествайте:

 sh$ /opt/node/bin/node --version v8.1.1 

Б. Какво става, ако нещата се объркат при инсталирането от изходния код?

Това, което обясних по-горе, е най-вече това, което можете да видите на страницата „Изграждане на инструкции“ на добре документиран проект. Но като се има предвид целта на тази статия е да ви позволим да компилирате първия си софтуер от източници, може би си струва да отделите време да проучите някои общи проблеми. Така че, ще направя цялата процедура отново, но този път от свежи и минимални Debian 9.0 и CentOS 7.0 системи. Така можете да видите грешката, която срещнах и как ги реших.

От Debian 9.0 „Stretch“

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

Този проблем е доста лесен за диагностициране и решаване. Просто инсталирайте пакета git :

 [email protected]:~$ sudo apt-get install git 
 [email protected]:~$ git clone --depth 1 \ --branch v8.1.1 \ //github.com/nodejs/node && echo ok [...] ok 
 [email protected]:~/node$ sudo mkdir /opt/node-v8.1.1 [email protected]:~/node$ sudo ln -sT node-v8.1.1 /opt/node 

Няма проблем тук.

 [email protected]:~/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. 

Очевидно е, че за да компилирате проект, имате нужда от компилатор. NodeJS се пише с C ++ език, ние се нуждаем от C ++ компилатор. Тук ще инсталирам `g ++ ', компилатора на GNU C ++ за тази цел:

 [email protected]:~/node$ sudo apt-get install g++ [email protected]:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok [...] ok 
 [email protected]:~/node$ make -j9 && echo ok -bash: make: command not found 

Един друг липсващ инструмент. Същите симптоми. Същото решение:

 [email protected]:~/node$ sudo apt-get install make [email protected]:~/node$ make -j9 && echo ok [...] ok 
 [email protected]:~/node$ sudo make install [...] [email protected]:~/node$ /opt/node/bin/node --version v8.1.1 

Успех!

Моля, обърнете внимание: Инсталирах различните инструменти едно по едно, за да покажа как да диагностицирам проблемите при компилирането и да ви покажа типичното решение за решаване на тези проблеми. Но ако потърсите повече за тази тема или прочетете други уроци, ще откриете, че повечето дистрибуции имат „метапакети“, които действат като чадър, за да инсталират някои или всички типични инструменти, използвани за компилиране на софтуер. За системите, базирани на Debian, вероятно ще срещнете пакета build-essentials за тази цел. А за дистрибуциите, базирани на Red-Hat, това ще бъде групата „Инструменти за разработка“ .

От CentOS 7.0

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

Командата не е намерена? Просто го инсталирайте с помощта на yum пакетния мениджър:

 [[email protected] ~]$ sudo yum install git 
 [[email protected] ~]$ git clone --depth 1 \ --branch v8.1.1 \ //github.com/nodejs/node && echo ok [...] ok 
 [[email protected] ~]$ sudo mkdir /opt/node-v8.1.1 [[email protected] ~]$ sudo ln -sT node-v8.1.1 /opt/node 
 [[email protected] ~]$ cd node [[email protected] 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. 

Вие предполагате: NodeJS е написан на C ++ език, но моята система няма съответния компилатор. Yum за спасяване. Тъй като не съм редовен потребител на CentOS, всъщност трябваше да търся в интернет точното име на пакета, съдържащ компилатора g ++. Води ме до тази страница: //superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

 [[email protected] node]$ sudo yum install gcc-c++ [[email protected] node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok [...] ok 
 [[email protected] node]$ make -j9 && echo ok [...] ok 
 [[email protected] node]$ sudo make install && echo ok [...] ok 
 [[email protected] node]$ /opt/node/bin/node --version v8.1.1 

Успех. Отново.

В. Внасяне на промени в софтуера, инсталиран от изходния код

Можете да инсталирате софтуер от източника, защото имате нужда от много специфична версия, която не е налична в хранилището ви за дистрибуция. Или защото искате да промените тази програма. Или за отстраняване на грешка, или за добавяне на функция. В крайна сметка, отворен код е всичко за това. Така че ще се възползвам от тази възможност, за да ви дам вкус на силата, която имате под ръка, сега сте в състояние да съставите свой собствен софтуер.

Тук ще направим малка промяна в източниците на NodeJS. И ще видим дали нашата промяна ще бъде включена в компилираната версия на софтуера:

Отворете файла node/src/node.cc в любимия си текстов редактор (vim, nano, gedit, …). И се опитайте да намерите този фрагмент от код:

  if (debug_options.ParseOption(argv[0], 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); } 

Той е около линия 3830 на файла. След това променете реда, съдържащ printf да съответства на съответния ред:

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

След това се върнете към терминала. Преди да отидете по-нататък - и за да ви дадем по-добра представа за силата зад git - можете да проверите дали сте променили правилния файл:

 diff --git a/src/node.cc b/src/node.cc index 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[0], 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(); 

Трябва да видите „-“ (знак минус) преди линията, каквато беше преди да я промените. И „+“ (знак плюс) преди реда след промените.

Време е да прекомпилирате и преинсталирате софтуера си:

 make -j9 && sudo make install && echo ok [...] ok 

Този път единствената причина, поради която може да се провали, е, че сте направили печатна грешка, докато променяте кода. Ако случаят е такъв, отворете node/src/node.cc файла node/src/node.cc във вашия текстов редактор и поправете грешката.

След като сте успели да компилирате и инсталирате тази нова модифицирана версия на NodeJS, ще можете да проверите дали модификациите ви са вградени в софтуера:

 [email protected]:~/node$ /opt/node/bin/node --version v8.1.1 (compiled by myself) 

Честито! Направихте първата си промяна в програма с отворен код!

D. Нека черупката намери нашия софтуер за изграждане по избор

Може да сте забелязали досега, че винаги пусках новокомпилирания NodeJS софтуер, като посочих абсолютния път към двоичния файл.

 /opt/node/bin/node 

Работи. Но това е най-малко досадно. Всъщност съществуват два общи начина за това. Но за да ги разберем, първо трябва да знаете, че вашата черупка локализира изпълнимия файл, като ги търси само в директориите, определени от PATH обкръжението PATH .

 [email protected]:~/node$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games 

Тук, на тази Debian система, ако не посочите изрично никаква директория като част от име на команда, черупката първо ще потърси тази изпълнима програма в /usr/local/bin, след това ако не бъде намерена в /usr/bin, тогава ако не се намери в /bin след това, ако не се намери в /usr/local/games тогава, ако не се намери в /usr/games, тогава ако не се намери ... черупката ще докладва за грешка "команда не е намерена" .

Като се има предвид, че имаме два начина да направим команда достъпна за черупката: като я добавим към една от вече конфигурираните PATH директории. Или чрез добавяне на директорията, съдържаща нашия изпълним файл в PATH .

Добавяне на връзка от / usr / local / bin

Просто копирането на изпълнимия файл с двоичен възел от /opt/node/bin в /usr/local/bin би било лоша идея, тъй като по този начин изпълняваната програма вече няма да може да намери другите необходими компоненти, принадлежащи на /opt/node/ (това е обичайна практика за софтуера да намира файловете си за ресурси по отношение на собственото си местоположение).

Традиционният начин да направите това е чрез използване на символична връзка:

 [email protected]:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node [email protected]:~/node$ which -a node || echo not found /usr/local/bin/node [email protected]:~/node$ node --version v8.1.1 (compiled by myself) 

Това е просто и ефективно решение, особено ако софтуерен пакет е съставен само от няколко добре познати изпълними програми - тъй като трябва да създадете символична връзка за всяка команда, която се задейства от потребителя. Например, ако сте запознати с NodeJS, знаете приложението npm companion, което трябва да символизира от /usr/local/bin . Но аз ви оставих това като упражнение.

Промяна на PATH

Първо, ако сте опитали предходното решение, премахнете символната връзка на възела, създадена по-рано, за да започнете от ясно състояние:

 [email protected]:~/node$ sudo rm /usr/local/bin/node [email protected]:~/node$ which -a node || echo not found not found 

И сега, тук е магическата команда за промяна на PATH :

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

Просто казано, заместих съдържанието на PATH средата PATH с предишното му съдържание, но с представка от /opt/node/bin . Така че, както можете да си представите сега, черупката ще погледне първо в директорията /opt/node/bin за изпълними програми. Можем да потвърдим, че използваме which команда:

 [email protected]:~/node$ which -a node || echo not found /opt/node/bin/node [email protected]:~/node$ node --version v8.1.1 (compiled by myself) 

Докато решението за "връзка" е трайно, веднага щом създадете символната връзка в /usr/local/bin, промяната на PATH е ефективна само в текущата обвивка. Аз ви позволявам да направите някои проучвания сами, за да знаете как да направите промени в постоянните PATH . Като намек, това е свързано с вашия „профил“. Ако намерите решението, не се колебайте да го споделите с другите читатели, като използвате раздела за коментари по-долу!

Д. Как да премахнете този новоинсталиран софтуер от изходния код

Тъй като персонализираният ни компилиран софтуер NodeJS се намира напълно в директорията /opt/node-v8.1.1, премахването на този софтуер не е повече работа, отколкото използването на командата rm за премахване на тази директория:

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

Внимавайте: sudo и rm -rf са опасен коктейл! Винаги проверявайте вашата команда два пъти, преди да натиснете клавиша “enter”. Няма да получавате никакво потвърждаващо съобщение и няма да се възстановят, ако премахнете грешната директория…

След това, ако сте променили PATH, ще трябва да върнете тези промени. Което съвсем не е сложно.

И ако сте създали връзки от /usr/local/bin, ще трябва да ги премахнете всички:

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

Изчакайте? Къде беше адът на зависимостта?

Като последен коментар, ако прочетете за компилирането на собствен софтуер, може да сте чували за ада. Това е псевдоним за тази досадна ситуация, в която преди да можете успешно да компилирате софтуер, първо трябва да съставите предварително необходима библиотека, която от своя страна изисква друга библиотека, която от своя страна може да бъде несъвместима с друг софтуер, който вече сте инсталирани.

Част от задачата на поддръжниците на пакети от вашата дистрибуция е да решат този адски дял и да гарантират, че различният софтуер на вашата система използва съвместими библиотеки и са инсталирани в правилния ред.

В тази статия избрах с цел да инсталирам NodeJS, тъй като на практика няма зависимости. Казах „виртуално“, защото всъщност има зависимости. Но изходният код на тези зависимости присъства в изходното хранилище на проекта (в поддиректорията node/deps ), така че не е нужно да ги изтегляте и инсталирате ръчно преди ръчно.

Но ако ви интересува повече за този проблем и се научите как да се справите с него, кажете ми, че използвайки раздела за коментари по-долу: това ще бъде чудесна тема за по-напреднала статия!

Препоръчано

Двигателят на Microsoft Edge за JavaScript е отворен код
2019
Върнете стария си компютър обратно в живота с 4MLinux
2019
Fix Невъзможност за влизане в Ubuntu след надстройка
2019