详解如何用源代码安装软件，以及如何卸载它
编译 安装 源代码
![How to install software from source code](/data/attachment/album/201712/25/215040sjoviquqilz5igl9.jpg)


*简介：这篇文章详细介绍了在 Linux 中怎么用源代码安装程序，以及怎么去卸载用源代码安装的程序。*


Linux 发行版的一个最大的优点就是它的包管理器和相关的软件库。通过它们提供的资源和工具，你才能够以完全自动化的方式在你的计算机上下载和安装软件。


但是，尽管付出了很多的努力，包维护者仍然没法照顾好每种情况，也不可能将所有的可用软件都打包进去。因此，仍然存在需要你自已去编译和安装一个新软件的情形。对于我来说，到目前为止，最主要的原因是，我编译一些软件是我需要去运行一个特定的版本。或者是我想去修改源代码或使用一些想要的编译选项。


如果你也属于后一种情况，那你已经知道你应该怎么做了。但是，对于绝大多数的 Linux 用户来说，第一次从源代码中编译和安装一个软件看上去像是一个入门仪式：它让很多人感到恐惧；但是，如果你能克服困难，你将可能进入一个全新的世界，并且，如果你做到了，那么你将成为社区中享有特权的一部分人。


* [建议阅读：怎样在 Ubuntu 中安装和删除软件（完全指南）](https://itsfoss.com/remove-install-software-ubuntu/)


### A. 在 Linux 中从源代码开始安装软件


这正是我们要做的。因为这篇文章的需要，我要在我的系统上安装 [NodeJS](https://nodejs.org/en/) 8.1.1。它是个完全真实的版本。这个版本在 Debian 仓库中没有：



```
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

```

#### 第 1 步：从 GitHub 上获取源代码


像大多数开源项目一样，NodeJS 的源代码可以在 GitHub：<https://github.com/nodejs/node> 上找到。


所以，我们直接开始吧。


![The NodeJS official GitHub repository](/data/attachment/album/201712/25/215041pz3g8mlejgd9g8hs.png)


如果你不熟悉 [GitHub](https://en.wikipedia.org/wiki/GitHub)，[git](https://en.wikipedia.org/wiki/Git) 或者提到的其它 [版本管理系统](https://en.wikipedia.org/wiki/Version_control)包含了这个软件的源代码，以及多年来对该软件的所有修改的历史。甚至可以回溯到该软件的最早版本。对于开发者来说，保留它的历史版本有很多好处。如今对我来说，其中一个好处是可以得到任何一个给定时间点的项目源代码。更准确地说，我可以得到我所要的 8.1.1 发布时的源代码。即便从那之后他们有了很多的修改。


![Choose the v8.1.1 tag in the NodeJS GitHub repository](/data/attachment/album/201712/25/215042bvodebvmz1thejbd.png)


在 GitHub 上，你可以使用 “branch” （分支）按钮导航到这个软件的不同版本。[“分支” 和 “标签” 是 Git 中一些相关的概念](https://stackoverflow.com/questions/1457103/how-is-a-tag-different-from-a-branch-which-should-i-use-here)。总的来说，开发者创建 “分支” 和 “标签” 来在项目历史中对重要事件保持跟踪，比如当他们启用一个新特性或者发布一个新版本时。在这里先不详细介绍了，你现在只需要知道我在找被标记为 “v8.1.1” 的版本。


![The NodeJS GitHub repository as it was at the time the v8.1.1 tag was created](/data/attachment/album/201712/25/215043xwvw1q088qnenbql.png)


在选择了 “v8.1.1” 标签后，页面被刷新，最显著的变化是标签现在作为 URL 的一部分出现。另外，你可能会注意到文件改变日期也有所不同。你现在看到的源代码树是创建了 v8.1.1 标签时的代码。在某种意义上，你也可以认为像 git 这样的版本管理工具是一个时光穿梭机，允许你在项目历史中来回穿梭。


![NodeJS GitHub repository download as a ZIP button](/data/attachment/album/201712/25/215044c9wv58g8z7wgqqqg.png)


此时，我们可以下载 NodeJS 8.1.1 的源代码。你不要忘记去点那个建议的大的蓝色按钮来下载一个项目的 ZIP 压缩包。对于我来说，为讲解的目的，我从命令行中下载并解压这个 ZIP 压缩包。但是，如果你更喜欢使用一个 [GUI](https://en.wikipedia.org/wiki/Graphical_user_interface) 工具，不用担心，你可以取代下面的命令方式：



```
wget https://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 \
              https://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 风格的构建系统](https://en.wikipedia.org/wiki/GNU_Build_System)。这在开源社区中这是一个很流行的选择。由此开始，你将进入一段精彩的旅程。


写出和调优一个构建系统是一个非常复杂的任务。但是，作为 “终端用户” 来说，GNU 风格的构建系统使用两个工具让他们免于此难：`configure` 和 `make`。


`configure` 文件是个项目专用的脚本，它将检查目标系统的配置和可用功能，以确保该项目可以被构建，并最终吻合当前平台的特性。


一个典型的 `configure` 任务的重要部分是去构建 `Makefile`。这个文件包含了有效构建项目所需的指令。


另一方面，[`make` 工具](https://en.wikipedia.org/wiki/Make_%28software)，这是一个可用于任何类 Unix 系统的 POSIX 工具。它将读取项目专用的 `Makefile` 然后执行所需的操作去构建和安装你的程序。


但是，在 Linux 的世界中，你仍然有一些定制你自己专用的构建的理由。



```
./configure --help

```

`configure -help` 命令将展示你可用的所有配置选项。再强调一下，这是非常的项目专用。说实话，有时候，在你完全理解每个配置选项的作用之前，你需要深入到项目中去好好研究。


不过，这里至少有一个标准的 GNU 自动化工具选项是你该知道的，它就是众所周知的 `--prefix` 选项。它与文件系统的层次结构有关，它是你软件要安装的位置。


#### 第 3 步：文件系统层次化标准（FHS）


大部分典型的 Linux 发行版的文件系统层次结构都遵从 [文件系统层次化标准（FHS）](http://www.pathname.com/fhs/)。


这个标准说明了你的系统中各种目录的用途，比如，`/usr`、`/tmp`、`/var` 等等。


当使用 GNU 自动化工具 *和大多数其它的构建系统* 时，它会把新软件默认安装在你的系统的 `/usr/local` 目录中。这是依据 FHS 中 *“`/usr/local` 层级是为系统管理员本地安装软件时使用的，它在系统软件更新覆盖时是安全的。它也可以用于存放在一组主机中共享，但又没有放到 /usr 中的程序和数据”*，因此，它是一个非常好的选择。


`/usr/local` 层级以某种方式复制了根目录，你可以在 `/usr/local/bin` 这里找到可执行程序，在 `/usr/local/lib` 中找到库，在 `/usr/local/share` 中找到架构无关的文件，等等。


使用 `/usr/local` 树作为你定制安装的软件位置的唯一问题是，你的软件的文件将在这里混杂在一起。尤其是你安装了多个软件之后，将很难去准确地跟踪 `/usr/local/bin` 和 `/usr/local/lib` 中的哪个文件到底属于哪个软件。它虽然不会导致系统的问题。毕竟，`/usr/bin` 也是一样混乱的。但是，有一天你想去卸载一个手工安装的软件时它会将成为一个问题。


要解决这个问题，我通常喜欢安装定制的软件到 `/opt` 子目录下。再次引用 FHS：



> 
> “`/opt` 是为安装附加的应用程序软件包而保留的。
> 
> 
> 包安装在 `/opt` 下的软件包必须将它的静态文件放在单独的 `/opt/<package>` 或者 `/opt/<provider>` 目录中，此处 `<package>` 是所说的那个软件名的名字，而 `<provider>` 处是提供者的 LANANA 注册名字。”（LCTT 译注：LANANA 是指 [The Linux Assigned Names And Numbers Authority](http://www.lanana.org/)。 ）
> 
> 
> 


因此，我们将在 `/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` 命令之后，如果有任何的除了 “ok” 以外的信息，将意味着在构建过程中有错误。当我们使用一个 `-j` 选项去运行并行构建时，在构建系统的大量输出过程中，检索错误信息并不是件很容易的事。


在这种情况下，只能是重新开始 `make`，并且不要使用 `-j` 选项。这样错误将会出现在输出信息的最后面：



```
sh$ make

```

最终，编译结束后，你可以运行这个命令去安装你的软件：



```
sh$ sudo make install

```

然后测试它：



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

```

### B. 如果在源代码安装的过程中出现错误怎么办？


我上面介绍的大多是你能在文档完备的项目的“构建指令”页面上看到。但是，本文的目标是让你从源代码开始去编译你的第一个软件，它可能要花一些时间去研究一些常见的问题。因此，我将再次重新开始一遍整个过程，但是，这次是在一个最新的、最小化安装的 Debian 9.0 和 CentOS 7.0 系统上。因此，你可能看到我遇到的错误以及我怎么去解决它。


#### 从 Debian 9.0 中 “Stretch” 开始



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

```

这个问题非常容易去诊断和解决。去安装这个 `git` 包即可：



```
itsfoss@debian:~$ sudo apt-get install git

```


```
itsfoss@debian:~$ git clone --depth 1 \
                             --branch v8.1.1 \
                             https://github.com/nodejs/node && echo ok
[...]
ok

```


```
itsfoss@debian:~/node$ sudo mkdir /opt/node-v8.1.1
itsfoss@debian:~/node$ sudo ln -sT node-v8.1.1 /opt/node

```

现在没有问题了。



```
itsfoss@debian:~/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++ 语言](https://en.wikipedia.org/wiki/C%2B%2B) 写的，我们需要一个 C++ [编译器](https://en.wikipedia.org/wiki/Compiler)。在这里我将安装 `g++`，它就是为这个目的写的 GNU C++ 编译器：



```
itsfoss@debian:~/node$ sudo apt-get install g++
itsfoss@debian:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok

```


```
itsfoss@debian:~/node$ make -j9 && echo ok
-bash: make: command not found

```

还差一个其它工具。同样的症状。同样的解决方案：



```
itsfoss@debian:~/node$ sudo apt-get install make
itsfoss@debian:~/node$ make -j9 && echo ok
[...]
ok

```


```
itsfoss@debian:~/node$ sudo make install
[...]
itsfoss@debian:~/node$ /opt/node/bin/node --version
v8.1.1

```

成功！


请注意：我将一次又一次地安装各种工具去展示怎么去诊断编译问题，以及展示怎么去解决这些问题。但是，如果你搜索关于这个主题的更多文档，或者读其它的教程，你将发现，很多发行版有一个 “meta-packages”，它包罗了安装一些或者全部的用于编译软件的常用工具。在基于 Debian 的系统上，你或许遇到过 [build-essentials](https://packages.debian.org/sid/build-essential) 包，它就是这种用作。在基于 Red Hat 的发行版中，它将是 *“Development Tools”* 组。


#### 在 CentOS 7.0 上



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

```

命令没有找到？可以用 `yum` 包管理器去安装它：



```
[itsfoss@centos ~]$ sudo yum install git

```


```
[itsfoss@centos ~]$ git clone --depth 1 \
                               --branch v8.1.1 \
                               https://github.com/nodejs/node && echo ok
[...]
ok

```


```
[itsfoss@centos ~]$ sudo mkdir /opt/node-v8.1.1
[itsfoss@centos ~]$ sudo ln -sT node-v8.1.1 /opt/node

```


```
[itsfoss@centos ~]$ cd node
[itsfoss@centos 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++ 编译器的包的确切名字的。这个页面指导了我：<https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4> 。



```
[itsfoss@centos node]$ sudo yum install gcc-c++
[itsfoss@centos node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok

```


```
[itsfoss@centos node]$ make -j9 && echo ok
[...]
ok

```


```
[itsfoss@centos node]$ sudo make install && echo ok
[...]
ok

```


```
[itsfoss@centos node]$ /opt/node/bin/node --version
v8.1.1

```

再次成功！


### C. 从源代码中对要安装的软件做一些改变


从源代码中安装一个软件，可能是因为你的分发仓库中没有一个可用的特定版本。或者因为你想去 *修改* 那个程序。也可能是修复一个 bug 或者增加一个特性。毕竟，开源软件这些都可以做到。因此，我将抓住这个机会，让你亲自体验怎么去编译你自己的软件。


在这里，我将在 NodeJS 源代码上做一个微小改变。然后，我们将看到我们的改变将被纳入到软件的编译版本中：


用你喜欢的 [文本编辑器](https://en.wikipedia.org/wiki/List_of_text_editors)（如，vim、nano、gedit、 … ）打开文件 `node/src/node.cc`。然后，尝试找到如下的代码片段：



```
   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 行](https://github.com/nodejs/node/blob/v8.1.1/src/node.cc#L3830) 附近。然后，修改包含 `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` 文件并修复错误。


一旦你完成了新修改版本的 NodeJS 的编译和安装，就可以去检查你的修改是否包含到软件中：



```
itsfoss@debian:~/node$ /opt/node/bin/node --version
v8.1.1 (compiled by myself)

```

恭喜你！你对开源程序做出了你的第一个改变！


### D. 让 shell 找到我们定制构建的软件


到目前为止，你可能注意到，我通常启动我新编译的 NodeJS 软件是通过指定到该二进制文件的绝对路径。



```
/opt/node/bin/node

```

这是可以正常工作的。但是，这样太麻烦。实际上有两种办法可以去解决这个问题。但是，去理解它们，你必须首先明白，你的 shell 定位可执行文件是通过在[环境变量](https://en.wikipedia.org/wiki/Environment_variable) `PATH` 中指定的目录里面查找的。



```
itsfoss@debian:~/node$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

```

在这个 Debian 系统上，如果你不指定一个精确的目录做为命令名字的一部分，shell 将首先在 `/usr/local/bin` 中查找可执行程序；如果没有找到，然后进入 `/usr/bin` 中查找；如果没有找到，然后进入 `/bin`查找；如果没有找到，然后进入 `/usr/local/games` 查找；如果没有找到，然后进入 `/usr/games` 查找；如果没有找到，那么，shell 将报告一个错误，*“command not found”*。


由此，我们可以知道有两种方法去确保命令可以被 shell 访问到：将它（该二进制程序）增加到已经配置好的 `PATH` 目录中，或者将包含可执行程序的目录添加到 `PATH` 中。


#### 从 /usr/local/bin 中添加一个链接


只是从 `/opt/node/bin` 中 *拷贝* NodeJS 二进制可执行文件到 `/usr/local/bin` 是一个错误的做法。因为，如果这么做，该可执行程序将无法定位到在 `/opt/node/` 中的需要的其它组件。（软件以它自己的位置去定位它所需要的资源文件是常见的做法）


因此，传统的做法是去使用一个符号链接：



```
itsfoss@debian:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node
itsfoss@debian:~/node$ which -a node || echo not found
/usr/local/bin/node
itsfoss@debian:~/node$ node --version
v8.1.1 (compiled by myself)

```

这一个简单而有效的解决办法，尤其是，如果一个软件包是由好几个众所周知的可执行程序组成的，因为，你将为每个用户调用的命令创建一个符号链接。例如，如果你熟悉 NodeJS，你知道应用的 `npm` 组件，也应该从 `/usr/local/bin` 做个符号链接。我把这个留给你做练习。


#### 修改 PATH


首先，如果你尝试过前面的解决方案，请先移除前面创建的节点符号链接，去从一个干净的状态开始：



```
itsfoss@debian:~/node$ sudo rm /usr/local/bin/node
itsfoss@debian:~/node$ which -a node || echo not found
not found

```

现在，这里有一个改变你的 `PATH` 的魔法命令：



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

```

简单说就是，我用环境变量 `PATH` 之前的内容前缀了一个 `/opt/node/bin` 替换了其原先的内容。因此，你可以想像一下，shell 将先进入到 `/opt/node/bin` 目录中查找可执行程序。我们也可以使用 `which` 命令去确认一下：



```
itsfoss@debian:~/node$ which -a node || echo not found
/opt/node/bin/node
itsfoss@debian:~/node$ node --version
v8.1.1 (compiled by myself)

```

鉴于 “符号链接” 解决方案是永久的，只要创建到 `/usr/local/bin` 的符号链接就行了，而对 `PATH` 的改变仅影响到当前的 shell。你可以自己做一些研究，如何做到对 `PATH` 的永久改变。给你一个提示，可以将它写到你的 “profile” 中。如果你找到这个解决方案，不要犹豫，通过下面的评论区共享给其它的读者！


### E. 怎么去卸载刚才从源代码中安装的软件


因为我们定制编译的 NodeJS 软件全部在 `/opt/node-v8.1.1` 目录中，卸载它不需要做太多的工作，仅使用 `rm` 命令去删除那个目录即可：



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

```

注意：`sudo` 和 `rm -rf` 是 “非常危险的鸡尾酒”！一定要在按下回车键之前多检查几次你的命令。你不会得到任何的确认信息，并且如果你删除了错误的目录它是不可恢复的 …


然后，如果你修改了你的 `PATH`，你可以去恢复这些改变。它一点也不复杂。


如果你从 `/usr/local/bin` 创建了一个符号链接，你应该去删除它们：



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

```

### 等等？ 依赖地狱在哪里？


作为最终的讨论，如果你读过有关的编译定制软件的文档，你可能听到关于 <ruby> <a href="https://en.wikipedia.org/wiki/Dependency_hell">  依赖地狱 </a> <rt>  dependency hell </rt></ruby> 的说法。那是在你能够成功编译一个软件之前，对那种烦人情况的一个别名，你必须首先编译一个前提条件所需要的库，它又可能要求其它的库，而这些库有可能与你的系统上已经安装的其它软件不兼容。


发行版的软件包维护者的部分工作，就是实际去地解决那些依赖地狱，确保你的系统上的各种软件都使用了兼容的库，并且按正确的顺序去安装。


在这篇文章中，我特意选择了 NodeJS 去安装，是因为它几乎没有依赖。我说 “几乎” 是因为，实际上，它 *有* 依赖。但是，这些源代码的依赖已经预置到项目的源仓库中（在 `node/deps` 子目录下），因此，在你动手编译之前，你不用手动去下载和安装它们。


如果你有兴趣了解更多关于那个问题的知识和学习怎么去处理它。请在下面的评论区告诉我，它将是更高级别的文章的好主题！




---


作者简介：


充满激情的工程师，职业是教师，我的目标是：热心分享我所教的内容，并让我的学生自己培养它们的技能。你也可以在我的网站上联系到我。




---


via: <https://itsfoss.com/install-software-from-source-code/>


作者：[Sylvain Leroux](https://itsfoss.com/author/sylvain/) 译者：[qhwdw](https://github.com/qhwdw) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
![Warp Terminal](/assets/images/warp-terminal.webp)


![Warp Terminal](/assets/images/warp-terminal.webp)

One of the greatest strength of your Linux distribution is its [package manager](https://itsfoss.com/package-manager/) and the associated software repository. With them, you have all the necessary tools and resources to download and install new software on your computer in a completely automated manner.

But despite all their efforts, the package maintainers cannot handle each and every use cases. Nor can they package all the software available out there. So there are still situations where you will have to compile and install new software by yourself. As for me, the most common reason, by far, I have to compile some software is when I need to run a very specific version, or modify the source code by the use of some fancy compilation options.

If your needs belong to the latter category, chances are you already know what to do. But, for the vast majority of Linux users, compiling and installing software from the source code for the first time might look like an initiation ceremony: somewhat frightening; but with the promise of entering a new world of possibilities and a place of prestige in a privileged community.

## A. Installing software from source code in Linux

And that’s exactly what we will do here. For the purpose of this article, let’s say I need to install [Node.js](https://nodejs.org/en/?ref=itsfoss.com) v8.1.1 on my system. That version exactly. A version which is not available from the Debian repository:

`apt-cache madison nodejs | grep amd64`


![Available Node.js versions in Debian](https://itsfoss.com/content/images/2023/05/available-nodejs-versions.png)

Now, [installing Node.js](https://itsfoss.com/install-nodejs-ubuntu/) on Ubuntu or Debian is pretty simple if you do it with the package manager. But let’s do it via the source code.

### Step 1: Getting the source code from GitHub

Like many open-source projects, the sources of Node.js can be found on GitHub. So, let’s go directly there.

![Node.js GitHub page](https://itsfoss.com/content/images/2023/05/nodejs-github-page.png)

If you’re not familiar with [GitHub](https://en.wikipedia.org/wiki/GitHub?ref=itsfoss.com), [git](https://itsfoss.com/basic-git-commands-cheat-sheet/) or [any other version control system](https://itsfoss.com/github-alternatives/) worth mentioning, the repository contains the current source for the software, as well as a history of all the modifications made through the years to that software. Eventually up to the very first line written for that project. For developers, keeping that history has many advantages. For us today, the main one is we will be able to get the sources from the project as they were at any given point in time. More precisely, I will be able to get the sources as they were when the 8.1.1 version I want was released. Even if there were many modifications since then.

![Select the required release tag for the package of your choice (In this case, Node.js v8.1.1)](https://itsfoss.com/content/images/2023/05/select-required-tag.png)

On GitHub, you can use the **branch** button to navigate between different versions of the software. [“Branch” and “tags” are somewhat related concepts in Git](https://stackoverflow.com/questions/1457103/how-is-a-tag-different-from-a-branch-which-should-i-use-here?ref=itsfoss.com). Basically, the developers create “branch” and “tags” to keep track of important events in the project history, like when they start working on a new feature or when they publish a release. I will not go into the details here, all you need to know is, I’m looking for the version *tagged***“v8.1.1”.**

![GitHub page of Node.js version 8.1.1](https://itsfoss.com/content/images/2023/05/nodejs-811-page.png)

After having chosen the “v8.1.1” tag, the page is refreshed, the most obvious change being the tag now appears as part of the URL. In addition, you will notice the file change dates are different too. The source tree you are now seeing is the one that existed at the time the v8.1.1 tag was created. In some sense, you can think of a version control tool like git as a time travel machine, allowing you to go back and forth in a project history.

![Use the "Code" button on the top right part to download the source code as a zip file](https://itsfoss.com/content/images/2023/05/download-source-code-as-zip.png)

At this point, we can download the sources of Node.js 8.1.1. You can’t miss the big button suggesting downloading the ZIP archive of the project. As for me, I will [download and extract the ZIP](https://itsfoss.com/unzip-linux/) from the command line for the sake of the explanation. But if you prefer using a [GUI](https://en.wikipedia.org/wiki/Graphical_user_interface?ref=itsfoss.com) tool, don’t hesitate to do that instead:

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


Downloading the ZIP archive works great. But if you want to do it “like a pro”, I would recommend using directly the `git`

tool to download the sources. It is not complicated at all — and it will be a nice first contact with a tool you will often encounter.

[ensure git is installed on your system](https://itsfoss.com/install-git-ubuntu/). Use sudo apt install git to quickly install git.

Make a shallow clone of the Node.js repository at v8.1.1

```
git clone --depth 1 \
--branch v8.1.1 \
https://github.com/nodejs/node
cd node/
```


By the way, if you have an issue, just consider the first part of this article as a general introduction. Later I have more detailed explanations for Debian and Red Hat based distributions in order to help you troubleshoot common issues.

Anyway, whenever you downloaded the source using `git`

or as a ZIP archive, you should now have exactly the same source files in the current directory:

![Contents of the Node.js cloned git repository is displayed using "ls" command](https://itsfoss.com/content/images/2023/05/inside-nodejs-extracted-repo.png)

### Step 2: Understanding the Build System of the program

We usually talk about “compiling the sources”, but the compilation is only one of the phases required to produce a working software from its source. A build system is a set of tools and practices used to automate and articulate those different tasks in order to build the software entirely just by issuing a few commands.

If the concept is simple, the reality is somewhat more complicated because different projects or programming languages may have different requirements. Or because of the programmer’s tastes. Or the supported platforms. Or for historical reasons. Or… or… there is an almost endless list of reasons to choose or create another build system. All that to say, there are many solutions used out there.

Node.js uses a [GNU-style build system](https://en.wikipedia.org/wiki/GNU_Build_System?ref=itsfoss.com). It is a popular choice in the open source community and, once again, a good way to start your journey.

Writing and tuning a build system is a pretty complex task, but for the “end user”, GNU-style build systems ease the task by using two tools: `configure`

and `make`

.

The `configure`

file is a project-specific script that will check the destination system configuration and available features in order to ensure the project can be built, eventually dealing with the specificities of the current platform.

An important part of a typical `configure`

job is to build the `Makefile`

. That is the file containing the instructions required to effectively build the project.

The [ make tool](https://en.wikipedia.org/wiki/Make_(software)?ref=itsfoss.com), on the other hand, is a POSIX tool available on any Unix-like system. It will read the project-specific

`Makefile`

and perform the required operations to build and install your program.But, as always in the Linux world, you still have some leniency in customizing the build to your specific needs.

`./configure --help`


The `configure -help`

command will show you all the available configuration options. Once again, this is very project-specific. And to be honest, it is sometimes necessary to dig into the project before fully understanding the meaning of each and every configure option.

But there is at least one standard GNU Autotools option that you must know: the `--prefix`

option. This has to do with the file system hierarchy and the place your software will be installed.

### Step 3: The FHS

The Linux file system hierarchy on a typical distribution mostly complies with the [Filesystem Hierarchy Standard (FHS)](https://linuxhandbook.com/linux-directory-structure/).

That standard explains the [purpose of the various directories of your system](https://linuxhandbook.com/linux-directory-structure/): `/usr`

, `/tmp`

, `/var`

and so on.

When using the GNU Autotools— and most other build systems— the default installation location for your new software will be `/usr/local`

. This is a good choice because according to the FSH:


*The /usr/local hierarchy is for use by the system administrator when installing software locally? It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.*The `/usr/local`

hierarchy somehow replicates the root directory, and you will find there `/usr/local/bin`

for the executable programs, `/usr/local/lib`

for the libraries, `/usr/local/share`

for architecture-independent files and so on.

The only issue when using the `/usr/local`

tree for custom software installation is the files for all your software will be mixed there. Especially after having installed a couple of software, it will be hard to track to which file exactly of `/usr/local/bin`

and `/usr/local/lib`

belongs to which software. That will not cause any issues to the system though. After all, `/usr/bin`

is just about the same mess. But that will become an issue the day you will want to remove manually installed software.

To solve that issue, I usually prefer installing custom software in the `/opt`

subtree instead. Once again, to quote the FHS:

*A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider’s LANANA registered name.*

*/opt is reserved for the installation of add-on application software packages.*So we will create a subdirectory of `/opt`

specifically for our custom Node.js installation. And if someday I want to remove that software, I will simply have to remove that directory:

```
sudo mkdir /opt/node-v8.1.1
sudo ln -sT node-v8.1.1 /opt/node
```


```
./configure --prefix=/opt/node-v8.1.1
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).

Anything but “**ok**” after the `make`

command has been completed would mean there was an error during the build process. As we ran a parallel build because of the `-j`

option, it is not always easy to retrieve the error message given the large volume of output produced by the build system.

In the case of an issue, just restart `make`

, but without the `-j`

option this time. And the error should appear near the end of the output:

`make`


Finally, once the compilation has gone to the end, you can install your software to its location by running the command:

`sudo make install`


And test it:

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


## B. What if things go wrong while installing from source code?

What I’ve explained above is mostly what you can see on the “build instruction” page of a well-documented project. But given this article's goal is to let you compile your first software from sources, it might be worth taking the time to investigate some common issues. So, I will do the whole procedure again, but this time from a fresh and minimal Debian and CentOS systems, so you can see the errors I encountered and how I solved them.

### From Debian “Stretch”

```
itsfoss@debian:~$ git clone --depth 1 \
--branch v8.1.1 \
https://github.com/nodejs/node
```


**Problem: Git command not found**

![If git not installed on your system, it will throw an error](https://itsfoss.com/content/images/2023/05/git-not-found.png)

This problem is quite easy to diagnose and solve. Just install the `git`

package:

```
itsfoss@debian:~$ sudo apt install git
```


```
itsfoss@debian:~$ git clone --depth 1 \
--branch v8.1.1 \
https://github.com/nodejs/node && echo ok
[...]
ok
```


```
itsfoss@debian:~/node$ sudo mkdir /opt/node-v8.1.1
itsfoss@debian:~/node$ sudo ln -sT node-v8.1.1 /opt/node
```


No problem here.

`itsfoss@debian:~/node$ ./configure --prefix=/opt/node-v8.1.1/`


**Problem: No acceptable C compiler found!**

![No C Compiler Found Error](https://itsfoss.com/content/images/2023/05/no-c-compiler-found-1.png)

![Pyhton Error in Node.js v8.1.1](https://itsfoss.com/content/images/2023/05/python-error.png)

Obviously, to compile a project, you need a compiler. Node.js being written using the [C++ language](https://en.wikipedia.org/wiki/C%2B%2B?ref=itsfoss.com), we require a C++ [compiler](https://en.wikipedia.org/wiki/Compiler?ref=itsfoss.com). Here I will install `g++`

, the GNU C++ compiler for that purpose:

```
itsfoss@debian:~/node$ sudo apt-get install g++
itsfoss@debian:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok
```


`itsfoss@debian:~/node$ make -j9 && echo ok`


**Problem: make command not found**

!["make" commadn not found error](https://itsfoss.com/content/images/2023/05/make-not-found.png)

`make`

command not foundOne other missing tool. Same symptoms. Same solution:

```
itsfoss@debian:~/node$ sudo apt-get install make
itsfoss@debian:~/node$ make -j9 && echo ok
[...]
ok
```


```
itsfoss@debian:~/node$ sudo make install
[...]
itsfoss@debian:~/node$ /opt/node/bin/node --version
v8.1.1
```


Success!

[build-essentials](https://itsfoss.com/build-essential-ubuntu/)package for that purpose. And on Red-Hat-based distributions, that will be the

*group.*

*“Development Tools”*### From CentOS

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


Command not found? Just install it using the `yum`

package manager:

```
[itsfoss@centos ~]$ sudo yum install git
```


```
[itsfoss@centos ~]$ git clone --depth 1 \
--branch v8.1.1 \
https://github.com/nodejs/node && echo ok
[...]
ok
```


```
[itsfoss@centos ~]$ sudo mkdir /opt/node-v8.1.1
[itsfoss@centos ~]$ sudo ln -sT node-v8.1.1 /opt/node
```


```
[itsfoss@centos ~]$ cd node
[itsfoss@centos 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.
```


You guess it: NodeJS is written using the C++ language, but my system lacks the corresponding compiler. Yum to the rescue. As I’m not a regular CentOS user, I actually had to search on the Internet the exact name of the package containing the g++ compiler.

Leading me to that page: [https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4](https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4?ref=itsfoss.com)

```
[itsfoss@centos node]$ sudo yum install gcc-c++
[itsfoss@centos node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok
```


```
[itsfoss@centos node]$ make -j9 && echo ok
[...]
ok
```


```
[itsfoss@centos node]$ sudo make install && echo ok
[...]
ok
```


```
[itsfoss@centos node]$ /opt/node/bin/node --version
v8.1.1
```


Success again!

## C. Making changes to the software installed from source code

You may install software from the source because you need a very specific version not available in your distribution repository or because you want to modify the program to fix a bug or add a feature. After all, open-source is all about making modifications. So, I will take this opportunity to give you a taste of the power you have at hand now that you are able to compile your own software.

Here, we will make a minor change to the sources of Node.js. And we will see if our change will be incorporated into the compiled version of the software:

Open the file `node/src/node.cc`

in your favorite [text editor](https://en.wikipedia.org/wiki/List_of_text_editors?ref=itsfoss.com) (vim, nano, gedit, … ). And try to locate that fragment of code:

```
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);
}
```


![The version number line in node.cc file](https://itsfoss.com/content/images/2023/05/change-node-cc-line.png)

It is around [line 3830 of the file](https://github.com/nodejs/node/blob/v8.1.1/src/node.cc?ref=itsfoss.com#L3830) in v8.1.1. Then modify the line containing `printf`

to match that one instead:

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


Then head back to your terminal. Before going further— and to give you some more insight of the power behind git— you can check if you’ve modified the right file:

`git diff`


!["git diff" command to show the changed line](https://itsfoss.com/content/images/2023/05/git-diff-1.png)

`git diff`

commandYou should see a “-” (minus sign) before the line as it was before you changed it. And a “+” (plus sign) before the line after your changes.

It is now time to recompile and re-install your software:

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


This times, the only reason it might fail is that you’ve made a typo while changing the code. If this is the case, re-open the `node/src/node.cc`

file in your text editor and fix the mistake.

Once you’ve managed to compile and install that new modified NodeJS version, you will be able to check if your modifications were actually incorporated into the software:

```
itsfoss@debian:~/node$ /opt/node/bin/node --version
v8.1.1 (compiled by myself)
```


Congratulations! You’ve made your first change to an open-source program!

## D. Let the shell locate our custom build software

You may have noticed that I’ve always launched my newly compiled NodeJS software by specifying the absolute path to the binary file.

`/opt/node/bin/node`


It works. But this is annoying, to say the least.

There are actually two common ways of fixing the annoying problem of specifying the absolute path to the binary files, but to understand them you must first know that your shell locates the executable files by looking for them only in the directories specified by the PATH [environment variable](https://en.wikipedia.org/wiki/Environment_variable?ref=itsfoss.com).

```
itsfoss@debian:~/node$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
```


Here, on that Debian system, if you do not specify explicitly any directory as part of a command name, the shell will first look for the executable programs in `/usr/local/bin`

, then if not found into `/usr/bin`

, then if not found into `/bin`

then if not found into `/usr/local/games`

then if not found into `/usr/games`

, then if not found … the shell will report an error *“command not found”*.

Given that, we have two way to make a command accessible to the shell: by adding it to one of the already configured `PATH`

directories. Or by [adding the directory containing our executable file to the PATH](https://itsfoss.com/add-directory-to-path-linux/).

### Adding a link from /usr/local/bin

Just *copying* the node binary executable from `/opt/node/bin`

to `/usr/local/bin`

would be a bad idea since by doing so, the executable program would no longer be able to locate the other required components belonging to `/opt/node/`

(it’s a common practice for software to locate its resource files relative to its own location).

So, the traditional way of doing that is by using a symbolic link:

```
itsfoss@debian:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node
itsfoss@debian:~/node$ which -a node || echo not found
/usr/local/bin/node
itsfoss@debian:~/node$ node --version
v8.1.1 (compiled by myself)
```


This is a simple and effective solution, especially if a software package is made of just few well known executable programs— since you have to create a symbolic link for each and every user-invokable command. For example, if you’re familiar with NodeJS, you know the `npm`

companion application I should symlink from `/usr/local/bin`

too. But I let that to you as an exercise.

### Modifying the PATH

First, if you tried the preceding solution, remove the node symbolic link created previously to start from a clear state:

```
itsfoss@debian:~/node$ sudo rm /usr/local/bin/node
itsfoss@debian:~/node$ which -a node || echo not found
not found
```


And now, here is the magic command to [change your PATH](https://itsfoss.com/add-directory-to-path-linux/):

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


Simply said, I replaced the content of the `PATH`

environment variable by its previous content, but prefixed by `/opt/node/bin`

. So, as you can imagine it now, the shell will look first into the `/opt/node/bin`

directory for executable programs. We can confirm that using the `which`

command:

```
itsfoss@debian:~/node$ which -a node || echo not found
/opt/node/bin/node
itsfoss@debian:~/node$ node --version
v8.1.1 (compiled by myself)
```


Whereas the “link” solution is permanent as soon as you’ve created the symbolic link into `/usr/local/bin`

, the `PATH`

change is effective only into the current shell. I will leave you to do some research on how to make changes in the `PATH`

permanents. As a hint, it has to do with your “profile”. If you find the solution, don’t hesitate to share that with the other readers by using the comment section below!

## E. How to remove that newly installed software from source code

Since our custom compiled NodeJS software sits completely in the `/opt/node-v8.1.1`

directory, removing that software requires no more effort than using the rm command to remove that directory:

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


**sudo and rm -rf are a dangerous cocktail! Always check your command twice before pressing the “enter” key. You won’t have any confirmation message and no undelete if you remove the wrong directory…**

**BEWARE:**Then, if you’ve modified your `PATH`

, you will have to revert those changes, which is not complicated at all.

And if you’ve created links from `/usr/local/bin`

you will have to remove them all:

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


## Wait? Where was the Dependency Hell?

As a final comment, if you read about compiling your own custom software, you might have heard about the [dependency hell](https://en.wikipedia.org/wiki/Dependency_hell?ref=itsfoss.com). This is a nickname for that annoying situation where before being able to successfully compile a software, you must first compile a pre-requisite library, which in its turn requires another library that might, in its turn, be incompatible with some other software you’ve already installed.

Part of the job of the package maintainers of your distribution is to actually resolve that dependency hell and to ensure the various software of your system are using compatible libraries and are installed in the right order.

For this article, I chose, on purpose, to install NodeJS as it virtually doesn’t have dependencies. I said “virtually” because, in fact, it *has* dependencies. But the source code of those dependencies are present in the source repository of the project (in the `node/deps`

subdirectory), so you don’t have to download and install them manually beforehand.

But if you’re interested in understanding more about that problem and learning how to deal with it, let me know in the comment section below: that would be a great topic for a more advanced article!