本来想写一大堆，后来发现这件事情在理论上是不可行的，然后就放弃了。

首先的原因是了解到作为gcc的C++标准库，libstdc++是后向兼容的（这里的“后”指时间上的“过去”），也就是说，新版本libstdc++支持旧版本编译出来的程序，而反过来不行。这是因为libstdc++库是以一种类似于增量更新的方式实现的，使用strings指令查看libstdc++.so文件可以发现，它包含了从最早版本以来一系列的符号支持，这也正是其后向兼容的原因。

由于没有前向兼容，导致过去的gcc不是适应未来的编译环境。以我的体验为例，用gcc 8.4.1编译gcc 4.9.4，前者的libstdc++的ABI应用二进制接口版本是CXXABI_1.3.9，而后者的只有CXXABI_1.3.8。

而问题正是出在这里。由于gcc和libstdc++属于紧密耦合的关系，gcc会使用自带的libstdc++而不是当前系统的版本来提供运行环境。使用了gcc 8.4.1编译的gcc 4.9.4自然是按照前者的运行库，使用了CXXABI_1.3.9；而当gcc 4.9.4运行的时候，从自己的libstdc++库里一翻，只支持到CXXABI_1.3.8，啪的一下就因为找不到符号报错了，很快啊。

当然这个可以通过使用LD_PRELOAD强行让gcc 4.9.4使用系统libstdc++库来解决这个问题，但是后面还有更麻烦的。我前几年编译gcc的文档里提到过，gcc的编译是自举的，相当于先编译gcc核心-编译c++库-再编译gcc扩展这个流程。

然而，使用LD_PRELOAD只是解决了第二步中的一个问题，重点在于libstdc++在版本更新的时候，可能不止更新ABI，还更新了上层的API，可能编着编着发现函数不见了，或者签名改了，直接报错中断，问题还没等到链接阶段就已经出现了。要解决这个问题约等于更改gcc对应的libstdc++库依赖，这严重违反了两者现有的紧密依赖的特点。这也正是我选择放弃降级编译gcc最主要的原因。

最后的结论是，CentOS 8是个什么垃圾东西，CentOS 7+devtoolset它不香吗

在读某篇文章的时候提到了乱序处理器的执行架构，其中有一个instruction commit/retire的概念没能很好地理解。后来在Wikipedia上看到了一段简短的文字（参见 https://en.wikipedia.org/wiki/Instruction_window ），有了一个初步的认识，在此记录一下。

首先是instruction window指令窗口（同ROB，Re-Order Buffer，重排序缓冲区）的概念。根据介绍，乱序执行模型实际上是一种整体上顺序、局部乱序的执行模型，允许处理器在执行某一指令时试探性地执行接下来的一些指令。为了确保尽可能大的预测有效率，处于乱序执行中的指令必须等待自己的操作数就绪才可以执行。

由于试探性执行的结果可能出现错误，而后需要通过状态回滚来撤销错误的执行操作，所以处于试探性执行阶段的指令需要单都标记出来，这便是指令窗口。处在指令窗口中的指令都处于执行中的状态，既可能是在正常按顺序执行，也可能是在乱序执行技术下提前执行。出于硬件设计合理性、执行效率等因素考虑，允许处于乱序执行状态下的指令数应该是有限的，也就意味着指令窗口是有大小限制的。

如果指令窗口中的指令执行结果确认无误，则可以提交执行结果，离开指令窗口，这个动作在英语中就称作instruction commit/retire。此时，下一条指令可以进入指令窗口，开始执行。

https://zhidao.baidu.com/question/1384876083010201380.html

chine这个词其实源于拉丁语的sina词根，法语可能把这个阴性也继承过去了，英语最明显China。就因为a结尾的在罗曼语及很多屈折语里多半都是阴性。而日本的发音来自汉字日本两字，最后本字有个鼻音韵尾，日本音读也继承了汉语的读法，而这个鼻音韵尾在屈折语里又多是阳性。原因大概就在这里。印欧语除了一些典型的可分阴阳的事物以外，大部分名词的阴阳都是随意分的。阴性、阳性也是翻译出来的说法。有的屈折语还有好几个性。

那为啥中国又是sina呢？渣浪爬啊

https://www.zhihu.com/question/382819849/answer/1109285663

据 https://www.etymonline.com/word/Sino- ：

Sino- before vowels Sin-, word-forming element meaning "Chinese," 1879, from Late Latin Sinæ (plural) "the Chinese," from Ptolemaic Greek Sinai, from Arabic Sin "China," probably from Chinese Ch'in, name of the fourth dynasty of China (see China).

拉丁语的「中国」是 Sinae （复数，理论上的单数当写作：Sina），源自托勒密希腊语的 Sinai，而托勒密希腊语的 Sinai 进而源自阿拉伯语Sin，最初的所指可能是汉语的「秦」。

但这哥们又提出了自己的观点：

疑点一：托勒密时代（前305-前30）的阿拉伯人尚处于蒙昧期，也没有与中国的直接接触，很难想象他们会先于希腊人知道中国。张骞第二次出使西域（前119），他的副使最西到达了安息（波斯帕提亚王朝）。安息与希腊人的塞琉古帝国接壤，塞琉古曾经统治整个波斯，安息就是由造反的波斯帕提亚部族所建立。当时波斯虽然大体「光复」，然而中亚、南亚仍有不少希腊的殖民王国存在。张骞副使所探访的身毒（印度）就是希腊的印度王国，而与月氏毗邻的大夏很可能就是希腊的巴克特里亚王国。所以说，托勒密的希腊人如果这个时候认识了中国，要么是从中亚的希腊人口中得知，要么是从波斯人、塞人、粟特人或者印度人这些跟汉已经有过直接接触的人口中得知。既没有直接接触、文化又较落后的阿拉伯人似乎排不上号。

疑点二：「秦」字是浊音声母，上古拟音作 * zin（郑张尚芳），中亚各族语言、希腊语、印度诸语中都存在浊擦音，不大可能把 zin 讹读成 sin 。反过来，「晋」是清音声母，上古拟音作 * ʔsins，（汉代时去声的后缀-s可能已经弱化成-h），Sinai更像是从这个音来的。

LaTeX一种规范的使用方法是，将文章内容按照节分开，储存在不同的文件中，然后再在主文件中使用\input{}指令引入所有需要的内容。这样做的好处是条理清晰，可以按照文件名管理内容，也便于缩短单文件文字长度，便于查找内容。

而TexLive自带的编辑器TeXworks默认会将需要编译的文件设置为当前的打开文件，直接编译显然会出错，而每次编译需要切回主TeX文件在操作上很麻烦。而TeXworks构造简单，没有项目的概念，因而巧妙地采用了LaTeX注释的方法建立文件见的联系。

通过在被引用TeX文件头部加入诸如

% !TeX root=main-document.tex

的注释，可以被TeXworks解析出来，不会以当前文件为主TeX文件，而是以main-document.tex为主文件进行编译。

需要注意的是，!TeX是一个整体，不能在!和TeX之间加入空格，否则TeXworks会识别不出来，继续按照单文件进行编译。

参考：https://tex.stackexchange.com/questions/377702/how-to-work-and-compile-efficiently-in-a-multi-file-project-in-texworks

这个问题一般出现在Windows环境下，采用\input{}指令导入的文件正确地与当前文件置于同一目录下，但LaTeX编译器还是获取不到。这可能与Windows下LaTeX的实现有关，在文件名中带空格的时候会出现这个问题，解决方法是将文件名用双引号"包裹起来。