合资企业的历史

Question

在使用 Intel core i5 的盒子上通过 18.04 进行测试并确认。

这说明了一切。要跳到“底线”，请查找“这是剧本”。

合资企业的历史

你可能已经看过这些，

如何运行“apt-get install”来安装所有依赖项？

添加 PPA 后如何解决未满足的依赖关系？

由于您想保留两个版本，因此这些方法实际上并不适用。还有其他问题/答案解决了强制安装依赖项的问题，但同样，这会让您得到“一个版本”而不是多个版本。

您遇到的依赖问题很可能源于升级（“替换”）的安装假设，而不是并行或独立（“补充”）。

存在安装多个版本的技术，但区分 7.3 和 7.5 可能会存在问题

如果可以“评论”，那么一个问题可能是这样的：

您是否也尝试过卸载现有版本并使用多版本技术重新安装？例如，

在 Ubuntu 14.04 上安装旧版 gcc（3.4.3）（目前安装的是 4.8）（其中包是，包是，以某种特殊性标识的）。
https://linuxize.com/post/how-to-install-gcc-compiler-on-ubuntu-18-04/

然而，需要区分 7.3 和 7.5，这与区分 7、8 和 9 不同，如该示例所示。

要尝试该技术，可能需要删除 7.5，然后将其安装在“替代”环境中。

移除至少会让我们走上以下两条路径中的一条。（提示：这会导致一堵砖墙，也许没关系。）

首先，只是进行基本的、全面的拆除。

https://www.youtube.com/watch?v=HKtjX_FBAnI（带有浓重非英语口音 - 集中注意力听就可以了）

在视频 5:38 处，大约 5:07 处，他讲到了关于卸载的“一句话”。他使用了purge，在多个网页上还有关于该过程的更多信息，包括此处：

https://vitux.com/how-to-uninstall-programs-from-your-ubuntu-system/

由于这里没有用处，因此没有为 7.5 设置“投资”，即没有爱损失，它成为了实验和测试的主题。

通过dpkg --list | more，

确定可能需要删除的软件包如下：

- g++-7                  7.5.0-3ubuntu1~18.04 
- gcc-7                  7.5.0-3ubuntu1~18.04 
- gcc-7-base:amd64       7.5.0-3ubuntu1~18.04

但是哪一个？

然后做

sudo apt search gcc-7 | more

得

gcc-7（7.5.0-3ubuntu1~18.04 amd64）。

因此，

sudo apt-get remove "gcc-7"

但是，在执行任何操作（例如按“y”）之前，请注意此删除操作包含的内容：build-essential、gcc和g++。我不想删除它们。

因此，其次，这引出了一个问题：是否存在部分移除这样的事情。（提示：有，但这可能不是一个好主意。）

如何删除 deb 而不删除其依赖项

所以，

（之后sudo apt-get install aptitude）（获得此功能是可以的，甚至是个好主意，但请继续阅读；这条路走到尽头了）

sudo aptitude unmarkauto build-essential gcc g++ [实际上并没有改变任何事情]

然后

sudo aptitude purge gcc-7

这将带我们进入“选项”列表，该系统有 6 个选项。

一次一个，选择 3（删除 7.5）（然后选择/输入“3”（当然不带引号）），5（保留 build-essential）（然后是 5），以及 6（保留 gcc）（然后是 6），然后选择 Y，删除 7.5 并保留 build-essential 和 gcc（对于最近重新安装的早期版本）。

并且，系统的后续操作是这样的：“无论如何，系统现在都将把它们全部删除”，这很可能是系统保护用户免受“rpm 地狱”侵害的方式，即在很大程度上防止这种事情，即部分删除。

由于那里的选项是删除所有内容，所以我停了下来。大约 5-6 小时后，我刚刚安装完我需要的先前版本，我不想再经历那样的过程。（这预示着先前版本现在存在并且安装得如此之好，以至于甚至会面临这种困境。）

这只是说，如果您想要保留的依赖关系中没有其他东西，那么这是彻底“删除”过程的替代方法，这两种方式都会让我们回到删除所有内容的相同位置。

也就是说，我没有回头重新审视这个问题，包括sudo ldconfig通过 unmarkauto 调整这些软件包后再运行并尝试部分删除机制。只要意识到“rpm 地狱”并不要急于进入就足够了。

全面移除之后，将采用双重或多版本安装技术，至少已经提到过对此的讨论，这只是此类选项存在的示例。同样，由于 gcc-7 目前指的是 7.5，因此，如果软件包识别足够明确，就有可能实现 7.3 和 7.5 的双重安装。还没有尝试过这样的事情。有经验的人将能够就整个事情的角度发表评论。也许真的有一个更简单的过程。

Shell 脚本简介

考虑到所有这些，以下是经过测试（使用 7.4，将 7.5 保留为“正式安装”版本）并确认的方法，用于在保留系统安装的 7.5 的同时安装先前版本。这是“困难的方法”。由于问题与“如何”完成这样的并行安装有关，因此答案是“这是实现目标的一种方法”。当然，这引出了一个非常重要的问题，即通过此过程生成的内容在全部完成后是否提供了可用的工具链。当然，这是您到达那里后需要确认的事情。这部分至少涉及确保您的 IDE（或用于编译、汇编、链接的任何方法）指向“正确”的工具集并包含库。因此，就“如何”而言，这是生成工具链先前版本的完整且独立安装的“困难方法”。完成此操作可能涉及设置ln -s链接或只是在 IDE 中添加替代路径以告诉 IDE 在哪里查找工具链。

这次，安装位置是 ~/opt ，即/home/<username>/opt。这是脚本中的设置，我将其保留为“原样”。一旦您尝试并发现它产生了您需要的结果，就可以将脚本设置更改为 $HOME ，例如 /opt （然后重新安装）。自生成代码的另一个位置是 /user/local。（您可能已经在脑海中有了这些“良好实践”的概念。）就我个人而言，一旦这得到证实，/opt 很可能是从头开始构建的工具链的“最终目的地”。目前，这个特定的驱动器被划分为一个巨大的、巨大的（这可能不是一个词，但在这里，它被使用，是一样的）“主”空间，并且正是针对这种情况：用于实验的空间不直接位于“系统文件区域”。

因此，在这种情况下，在您发布问题后的早期阶段，“解读沉默”的一种可能方法是，您需要的答案并不像已经存在的答案那么简单。如果这是对时间的有效“解读”，而且我对这个网站还不熟悉，那么无论如何，那么就有一个微妙的确认，即您正在查看的解决方案基本上是从头开始编译的，即“艰难的方式”。

脚本如下

现在，一切都不再像以前那么困难了。这在一定程度上要归功于达伦·史密斯。https://medium.com/@darrenjs/building-gcc-from-source-dcc368a3bb70，特别是，https://github.com/darrenjs/howto/blob/master/build_scripts/build_gcc_9.sh，这是他的安装脚本（为 9.1 设计）。他编写了一个脚本，其工作方式与脚本应有的工作方式一样。他编写该脚本时着眼于 9.1。经过一些适当的调整，它同样适用于旧版安装。他在这方面做得很好。

[至于解决未来可能出现过时/死链接的问题，如果您想包含对脚本所做的编辑，假设它对您和对我一样有效，我允许您发布它。这个贡献已经“很长”了。]

有一些想法。

查看脚本。确保您已安装wget并autogen运行。例如，经过两个小时的过程（如果我记得取消注释第 19 行以尝试使用多个核心，则可能不会花那么长时间），它在第一次运行时就退出了。为什么？因为我没有autogen安装。（这是最近重新安装的 18.04，有些东西我还没有重新安装，再次，还没有。）这方面有些努力白费，而不是从那个时刻“完成”，我需要删除两个编译/汇编结果的目录（当一个通过与最初使用的相同命令重新启动脚本时，脚本会识别哪两个；请确保在复制/粘贴脚本并添加下面的编辑并保存该文件（作为 .sh shell 脚本文件）后，以便sudo chmod +x <shellScriptName.sh>通过激活它./<shellScriptName.sh>），并且必须再次运行该部分，可能至少要花一个小时。这不是世界末日；只是令人沮丧。因此，查看脚本并检查找到的每个命令（例如 awk），以确保已安装该命令/实用程序。应该已经安装了，但无论如何检查一下也没问题。（我使用了“whereis”。）

查看脚本的另一个价值在于它涉及五个部分：

海湾合作委员会
绿肥
mpfr
mpc，和
伊斯拉

另见，例如， https://stackoverflow.com/questions/9450394/how-to-install-gcc-piece-by-piece-with-gmp-mpfr-mpc-elf-without-shared-libra

每个都有一个下载步骤，并且每个都有（至少）一个源。

配置很重要（是的，这里有两个含义）

对于 7.3，做了一些检查并在此页面上找到了有用的信息：

https://stackoverflow.com/questions/55084198/which-versions-of-gmp-mpc-and-mpfr-were-used-to-compile-gcc

在页面下方的一个答案中，有一行编译器输出，其中列出了与 7.3 一起工作的每个版本。

GNU C11（Ubuntu 7.3.0-27ubuntu1~18.04）版本 7.3.0（x86_64-linux-gnu）

由 GNU C 版本 7.3.0 编译，
GMP 版本 6.1.2，
mpfr 版本 4.0.1，
mpc 版本 1.1.0，
isl 版本 isl-0.19-GMP

因此，对 7.3 版脚本的一些“编辑”如下。

第 14 行 gcc_version=7.3.0
第 19 行如果您愿意，请取消注释此行。

有关使用多核的更多信息

（有人可能想要/需要这个。）

信息来自：https://baiweiblog.wordpress.com/2017/10/27/how-many-physical-and-logical-cpu-cores-in-your-computer/

运行此命令：lscpu

获取所需的信息，关于 -j 标志可以/应该使用什么值。

除其他信息外，该命令特别提供了以下内容：

CPU(s):   < a number, e.g., total >, a figure determined by multiplying these 
                                     additional items 
Thread(s) per core:     < a number, e.g., t/c >
Core(s) per socket:     < a number, e.g., c/s >
Socket(s):              < a number, e.g., s >

-j 数字 < 例如，总计 > = < t/c > * < c/s > * < s > = CPU(s)

在已识别的站点，CPU = 32 = < t/c = 2 > * < c/s = 8 > * < s = 2 >

在这个盒子上，CPS(s) = 4 = < t/c of 2 > * < c/s of 2 > * < s of 1 > 。因此，在这台特定的机器上，j 可能不应该大于 4。话虽如此，有些人建议重载 j 以确保它处于峰值。这留给每个开发人员去决定。

第 22 行
如果有疑问，只需检查任何 -verbose 编译列表中的 gcc 行，您可能必须确认机器的处理器（架构）。

运行gcc -v是尝试获取架构的另一种方法。

运行uname -m可能会好一点。在这个框中，uname -m返回的是“x86[下划线]64”。当然，对于选项来说，更好的语法-march=是 x86[连字符]64。

第 25 行
关于“未知”，长话短说，保持原样就可以了。
第 33 行 install_dir
如上所述，我将其保留为 $HOME，即 ~/。如果有变化，/opt 是一个不错的选择，或者 /usr/local。如果您已经知道其中任何一个是首选，那就太好了。我正在尝试在将其提交给正式的 $PATH 元素之前解决任何“唯一性”问题。
第 34 行 build_dir
此项设置为在“系统文件”区域中的 tmp 目录中构建。效果很好。
第 35 行 source_dir
保留此行不变。
第 36 行 tarfile_dir
保留原样。
第 40 行 packageversion
保留此行不变。
第 50 行 gmp_version
鉴于上面提到的与 7.3 相关的编译器信息，将此信息保留原样。
第 54 行 mpfr_version
鉴于上述编译器信息，将其更改为 4.0.1 似乎可以。
第 57 行 mpc_version
鉴于上述编译器信息，将其更改为 1.1.0 似乎可以。
第 60 行 isl_version
鉴于上述编译器信息，将其更改为 0.19 似乎可以。

第 153、154、155 行——下载源代码横幅

This is where it'll be good to confirm the URLs.

[you'll need `wget` -- install it if necessary]

170 行 gmp 源页面
完好无损
第 171 行 mpfr 源页面
脚本使用的页面也有 4.0.1 版本，所以这样就没问题了。
第 172 行 mpc 源页面
这是一个 http: 站点；因此，直接访问会产生访问错误。我将其保留为“原样”，没有出现任何问题。另一个站点是： https://ftp.gnu.org/gnu/mpc/。
第 173 行 isl 源页面
给定的基础设施页面有 0.18，但没有 0.19。我将其更改为此站点： http://isl.gforge.inria.fr/ （与该海外网站连接时出现了短暂的、仅一闪而过的暂停；连接正常）
第 174 行 gcc 源页面
将其更改为此站点： https://ftp.gnu.org/gnu/gcc/gcc-7.3.0/
第 224、225 行
保持原样
第 291 行
发生的情况足够多了，有必要取消注释此行以进行这些检查。

autogen在这里“最后”开始生成文档。

如果不设置 -j，并且利用标称 25 下载 / 6 上传的互联网连接，这个过程需要几个小时。

安装确认

我设置了 7.4，现在它位于 ~/opt 目录中。一旦确信这就是我所需要的，我可能会将其重新安装到 /opt (root/opt)。

也就是说，这是一个如何安装 7.3 以及系统“鼓励”使用 7.5 的指南。

概括。

shell 脚本用于安装工具链的并行版本。只需确保将所需的信息放入正确的位置，并已安装其使用的实用程序（函数、命令行命令）。“按原样”，它将安装到 ~/opt。这可能需要“一段时间”。在这里，它花了几个小时。

Answer 1

在使用 Intel core i5 的盒子上通过 18.04 进行测试并确认。

这说明了一切。要跳到“底线”，请查找“这是剧本”。

合资企业的历史

你可能已经看过这些，

如何运行“apt-get install”来安装所有依赖项？

添加 PPA 后如何解决未满足的依赖关系？

由于您想保留两个版本，因此这些方法实际上并不适用。还有其他问题/答案解决了强制安装依赖项的问题，但同样，这会让您得到“一个版本”而不是多个版本。

您遇到的依赖问题很可能源于升级（“替换”）的安装假设，而不是并行或独立（“补充”）。

存在安装多个版本的技术，但区分 7.3 和 7.5 可能会存在问题

如果可以“评论”，那么一个问题可能是这样的：

您是否也尝试过卸载现有版本并使用多版本技术重新安装？例如，

在 Ubuntu 14.04 上安装旧版 gcc（3.4.3）（目前安装的是 4.8）（其中包是，包是，以某种特殊性标识的）。
https://linuxize.com/post/how-to-install-gcc-compiler-on-ubuntu-18-04/

然而，需要区分 7.3 和 7.5，这与区分 7、8 和 9 不同，如该示例所示。

要尝试该技术，可能需要删除 7.5，然后将其安装在“替代”环境中。

移除至少会让我们走上以下两条路径中的一条。（提示：这会导致一堵砖墙，也许没关系。）

首先，只是进行基本的、全面的拆除。

https://www.youtube.com/watch?v=HKtjX_FBAnI（带有浓重非英语口音 - 集中注意力听就可以了）

在视频 5:38 处，大约 5:07 处，他讲到了关于卸载的“一句话”。他使用了purge，在多个网页上还有关于该过程的更多信息，包括此处：

https://vitux.com/how-to-uninstall-programs-from-your-ubuntu-system/

由于这里没有用处，因此没有为 7.5 设置“投资”，即没有爱损失，它成为了实验和测试的主题。

通过dpkg --list | more，

确定可能需要删除的软件包如下：

- g++-7                  7.5.0-3ubuntu1~18.04 
- gcc-7                  7.5.0-3ubuntu1~18.04 
- gcc-7-base:amd64       7.5.0-3ubuntu1~18.04

但是哪一个？

然后做

sudo apt search gcc-7 | more

得

gcc-7（7.5.0-3ubuntu1~18.04 amd64）。

因此，

sudo apt-get remove "gcc-7"

但是，在执行任何操作（例如按“y”）之前，请注意此删除操作包含的内容：build-essential、gcc和g++。我不想删除它们。

因此，其次，这引出了一个问题：是否存在部分移除这样的事情。（提示：有，但这可能不是一个好主意。）

如何删除 deb 而不删除其依赖项

所以，

（之后sudo apt-get install aptitude）（获得此功能是可以的，甚至是个好主意，但请继续阅读；这条路走到尽头了）

sudo aptitude unmarkauto build-essential gcc g++ [实际上并没有改变任何事情]

然后

sudo aptitude purge gcc-7

这将带我们进入“选项”列表，该系统有 6 个选项。

一次一个，选择 3（删除 7.5）（然后选择/输入“3”（当然不带引号）），5（保留 build-essential）（然后是 5），以及 6（保留 gcc）（然后是 6），然后选择 Y，删除 7.5 并保留 build-essential 和 gcc（对于最近重新安装的早期版本）。

并且，系统的后续操作是这样的：“无论如何，系统现在都将把它们全部删除”，这很可能是系统保护用户免受“rpm 地狱”侵害的方式，即在很大程度上防止这种事情，即部分删除。

由于那里的选项是删除所有内容，所以我停了下来。大约 5-6 小时后，我刚刚安装完我需要的先前版本，我不想再经历那样的过程。（这预示着先前版本现在存在并且安装得如此之好，以至于甚至会面临这种困境。）

这只是说，如果您想要保留的依赖关系中没有其他东西，那么这是彻底“删除”过程的替代方法，这两种方式都会让我们回到删除所有内容的相同位置。

也就是说，我没有回头重新审视这个问题，包括sudo ldconfig通过 unmarkauto 调整这些软件包后再运行并尝试部分删除机制。只要意识到“rpm 地狱”并不要急于进入就足够了。

全面移除之后，将采用双重或多版本安装技术，至少已经提到过对此的讨论，这只是此类选项存在的示例。同样，由于 gcc-7 目前指的是 7.5，因此，如果软件包识别足够明确，就有可能实现 7.3 和 7.5 的双重安装。还没有尝试过这样的事情。有经验的人将能够就整个事情的角度发表评论。也许真的有一个更简单的过程。

Shell 脚本简介

考虑到所有这些，以下是经过测试（使用 7.4，将 7.5 保留为“正式安装”版本）并确认的方法，用于在保留系统安装的 7.5 的同时安装先前版本。这是“困难的方法”。由于问题与“如何”完成这样的并行安装有关，因此答案是“这是实现目标的一种方法”。当然，这引出了一个非常重要的问题，即通过此过程生成的内容在全部完成后是否提供了可用的工具链。当然，这是您到达那里后需要确认的事情。这部分至少涉及确保您的 IDE（或用于编译、汇编、链接的任何方法）指向“正确”的工具集并包含库。因此，就“如何”而言，这是生成工具链先前版本的完整且独立安装的“困难方法”。完成此操作可能涉及设置ln -s链接或只是在 IDE 中添加替代路径以告诉 IDE 在哪里查找工具链。

这次，安装位置是 ~/opt ，即/home/<username>/opt。这是脚本中的设置，我将其保留为“原样”。一旦您尝试并发现它产生了您需要的结果，就可以将脚本设置更改为 $HOME ，例如 /opt （然后重新安装）。自生成代码的另一个位置是 /user/local。（您可能已经在脑海中有了这些“良好实践”的概念。）就我个人而言，一旦这得到证实，/opt 很可能是从头开始构建的工具链的“最终目的地”。目前，这个特定的驱动器被划分为一个巨大的、巨大的（这可能不是一个词，但在这里，它被使用，是一样的）“主”空间，并且正是针对这种情况：用于实验的空间不直接位于“系统文件区域”。

因此，在这种情况下，在您发布问题后的早期阶段，“解读沉默”的一种可能方法是，您需要的答案并不像已经存在的答案那么简单。如果这是对时间的有效“解读”，而且我对这个网站还不熟悉，那么无论如何，那么就有一个微妙的确认，即您正在查看的解决方案基本上是从头开始编译的，即“艰难的方式”。

脚本如下

现在，一切都不再像以前那么困难了。这在一定程度上要归功于达伦·史密斯。https://medium.com/@darrenjs/building-gcc-from-source-dcc368a3bb70，特别是，https://github.com/darrenjs/howto/blob/master/build_scripts/build_gcc_9.sh，这是他的安装脚本（为 9.1 设计）。他编写了一个脚本，其工作方式与脚本应有的工作方式一样。他编写该脚本时着眼于 9.1。经过一些适当的调整，它同样适用于旧版安装。他在这方面做得很好。

[至于解决未来可能出现过时/死链接的问题，如果您想包含对脚本所做的编辑，假设它对您和对我一样有效，我允许您发布它。这个贡献已经“很长”了。]

有一些想法。

查看脚本。确保您已安装wget并autogen运行。例如，经过两个小时的过程（如果我记得取消注释第 19 行以尝试使用多个核心，则可能不会花那么长时间），它在第一次运行时就退出了。为什么？因为我没有autogen安装。（这是最近重新安装的 18.04，有些东西我还没有重新安装，再次，还没有。）这方面有些努力白费，而不是从那个时刻“完成”，我需要删除两个编译/汇编结果的目录（当一个通过与最初使用的相同命令重新启动脚本时，脚本会识别哪两个；请确保在复制/粘贴脚本并添加下面的编辑并保存该文件（作为 .sh shell 脚本文件）后，以便sudo chmod +x <shellScriptName.sh>通过激活它./<shellScriptName.sh>），并且必须再次运行该部分，可能至少要花一个小时。这不是世界末日；只是令人沮丧。因此，查看脚本并检查找到的每个命令（例如 awk），以确保已安装该命令/实用程序。应该已经安装了，但无论如何检查一下也没问题。（我使用了“whereis”。）

查看脚本的另一个价值在于它涉及五个部分：

海湾合作委员会
绿肥
mpfr
mpc，和
伊斯拉

另见，例如， https://stackoverflow.com/questions/9450394/how-to-install-gcc-piece-by-piece-with-gmp-mpfr-mpc-elf-without-shared-libra

每个都有一个下载步骤，并且每个都有（至少）一个源。

配置很重要（是的，这里有两个含义）

对于 7.3，做了一些检查并在此页面上找到了有用的信息：

https://stackoverflow.com/questions/55084198/which-versions-of-gmp-mpc-and-mpfr-were-used-to-compile-gcc

在页面下方的一个答案中，有一行编译器输出，其中列出了与 7.3 一起工作的每个版本。

GNU C11（Ubuntu 7.3.0-27ubuntu1~18.04）版本 7.3.0（x86_64-linux-gnu）

由 GNU C 版本 7.3.0 编译，
GMP 版本 6.1.2，
mpfr 版本 4.0.1，
mpc 版本 1.1.0，
isl 版本 isl-0.19-GMP

因此，对 7.3 版脚本的一些“编辑”如下。

第 14 行 gcc_version=7.3.0
第 19 行如果您愿意，请取消注释此行。

有关使用多核的更多信息

（有人可能想要/需要这个。）

信息来自：https://baiweiblog.wordpress.com/2017/10/27/how-many-physical-and-logical-cpu-cores-in-your-computer/

运行此命令：lscpu

获取所需的信息，关于 -j 标志可以/应该使用什么值。

除其他信息外，该命令特别提供了以下内容：

CPU(s):   < a number, e.g., total >, a figure determined by multiplying these 
                                     additional items 
Thread(s) per core:     < a number, e.g., t/c >
Core(s) per socket:     < a number, e.g., c/s >
Socket(s):              < a number, e.g., s >

-j 数字 < 例如，总计 > = < t/c > * < c/s > * < s > = CPU(s)

在已识别的站点，CPU = 32 = < t/c = 2 > * < c/s = 8 > * < s = 2 >

在这个盒子上，CPS(s) = 4 = < t/c of 2 > * < c/s of 2 > * < s of 1 > 。因此，在这台特定的机器上，j 可能不应该大于 4。话虽如此，有些人建议重载 j 以确保它处于峰值。这留给每个开发人员去决定。

第 22 行
如果有疑问，只需检查任何 -verbose 编译列表中的 gcc 行，您可能必须确认机器的处理器（架构）。

运行gcc -v是尝试获取架构的另一种方法。

运行uname -m可能会好一点。在这个框中，uname -m返回的是“x86[下划线]64”。当然，对于选项来说，更好的语法-march=是 x86[连字符]64。

第 25 行
关于“未知”，长话短说，保持原样就可以了。
第 33 行 install_dir
如上所述，我将其保留为 $HOME，即 ~/。如果有变化，/opt 是一个不错的选择，或者 /usr/local。如果您已经知道其中任何一个是首选，那就太好了。我正在尝试在将其提交给正式的 $PATH 元素之前解决任何“唯一性”问题。
第 34 行 build_dir
此项设置为在“系统文件”区域中的 tmp 目录中构建。效果很好。
第 35 行 source_dir
保留此行不变。
第 36 行 tarfile_dir
保留原样。
第 40 行 packageversion
保留此行不变。
第 50 行 gmp_version
鉴于上面提到的与 7.3 相关的编译器信息，将此信息保留原样。
第 54 行 mpfr_version
鉴于上述编译器信息，将其更改为 4.0.1 似乎可以。
第 57 行 mpc_version
鉴于上述编译器信息，将其更改为 1.1.0 似乎可以。
第 60 行 isl_version
鉴于上述编译器信息，将其更改为 0.19 似乎可以。

第 153、154、155 行——下载源代码横幅

This is where it'll be good to confirm the URLs.

[you'll need `wget` -- install it if necessary]

170 行 gmp 源页面
完好无损
第 171 行 mpfr 源页面
脚本使用的页面也有 4.0.1 版本，所以这样就没问题了。
第 172 行 mpc 源页面
这是一个 http: 站点；因此，直接访问会产生访问错误。我将其保留为“原样”，没有出现任何问题。另一个站点是： https://ftp.gnu.org/gnu/mpc/。
第 173 行 isl 源页面
给定的基础设施页面有 0.18，但没有 0.19。我将其更改为此站点： http://isl.gforge.inria.fr/ （与该海外网站连接时出现了短暂的、仅一闪而过的暂停；连接正常）
第 174 行 gcc 源页面
将其更改为此站点： https://ftp.gnu.org/gnu/gcc/gcc-7.3.0/
第 224、225 行
保持原样
第 291 行
发生的情况足够多了，有必要取消注释此行以进行这些检查。

autogen在这里“最后”开始生成文档。

如果不设置 -j，并且利用标称 25 下载 / 6 上传的互联网连接，这个过程需要几个小时。

安装确认

我设置了 7.4，现在它位于 ~/opt 目录中。一旦确信这就是我所需要的，我可能会将其重新安装到 /opt (root/opt)。

也就是说，这是一个如何安装 7.3 以及系统“鼓励”使用 7.5 的指南。

概括。

shell 脚本用于安装工具链的并行版本。只需确保将所需的信息放入正确的位置，并已安装其使用的实用程序（函数、命令行命令）。“按原样”，它将安装到 ~/opt。这可能需要“一段时间”。在这里，它花了几个小时。

合资企业的历史

我目前所做的：

答案1

合资企业的历史

Shell 脚本简介

脚本如下

配置很重要（是的，这里有两个含义）

有关使用多核的更多信息

安装确认

相关内容