c++ - 为什么此代码链接到 Intel Compiler 2015 而不是 Intel Compiler 2018？

Question

我的团队最近从 2015 年英特尔编译器(并行工作室)升级到 2018 年版本，我们遇到了一个链接器问题，让每个人都焦头烂额。

我有以下类(为简洁起见进行了适度编辑)，用于处理子进程的包装以及与它们对话的相关文件描述符:

class SubprocWrapper
{
public:
    static const int PASSTHRU_FD = 0;
    static const int MAKE_PIPE = -1;

    typedef std::map<std::string, std::string> EnvMapType;

    static EnvMapType getMyEnv();

    SubprocWrapper(
        int stdin_fd_req,
        int stdout_fd_req,
        int stderr_fd_req,
        const std::string & execPath,
        const std::vector<std::string> & args,
        const std::set<int> & dont_close_fds,
        const EnvMapType * env = 0);
};

然后我使用以下代码调用它:

std::string runCmd = "/run/some/file.bin";
std::vector<std::string> args(2);
args[0] = "-c";
args[1] = runCmd;

SubprocWrapper::EnvMapType env_vars = SubprocWrapper::getMyEnv();

SubprocWrapper subproc(
    SubprocWrapper::PASSTHRU_FD,
    SubprocWrapper::PASSTHRU_FD,
    SubprocWrapper::PASSTHRU_FD,
    std::string("/bin/sh"),
    args,
    std::set<int>(), //dont_close_fds = null means "close all fds"
    &env_vars
);

在 2015 和 2018 Intel 编译器上，上述代码编译都很好。

但是，在 2018 Intel 编译器中，上述代码无法链接，而在 2015 Intel 编译器中，它可以正常链接。

错误似乎是链接器无法找到构造函数符号，因为我收到以下错误:

    SourceFile.o: in function <MangledName> SourceFile.hh:<LineNum>: undefined reference to 
`SubprocWrapper::SubprocWrapper(int, int, int, std::string const&,
 std::vector<std::string, std::allocator<std::string> > const&,
 std::set<int, std::less<int>, std::allocator<int> > const&,
 std::map<std::string, std::string, std::less<std::string>,
 std::allocator<std::pair<std::string const, std::string> > > const*)'

请注意，SubprocWrapper 类被编译成一个 .a 文件并静态链接到调用它的代码中。对生成的 .a 文件执行 nm 似乎确认存在 SubprocWrapper 构造函数的符号，但代码仅在 2015 下链接，即使原始 .a 是用 2018 编译的。我们已经确认正在传入正确的 .a 文件在链接器行上(我们的构建过程没有改变)，我们尝试在链接顺序中移动 .a 无济于事。

对我链接的 .a 文件执行 nm 会显示以下与构造函数关联的签名(lib.a 和 SourceFile.o 之间不同):

lib.a:

0000000000001020 T _ZN4beau5posix14SubprocWrapperC1EiiiRKSsRKSt6vectorISsSaISsEERKSt3setIiSt4lessIiESaIiEEPKSt3mapISsSsSA_ISsESaISt4pairIS2_SsEEE
0000000000000084 r _ZN4beau5posix14SubprocWrapperC1EiiiRKSsRKSt6vectorISsSaISsEERKSt3setIiSt4lessIiESaIiEEPKSt3mapISsSsSA_ISsESaISt4pairIS2_SsEEE$$LSDA
0000000000001010 T _ZN4beau5posix14SubprocWrapperC2EiiiRKSsRKSt6vectorISsSaISsEERKSt3setIiSt4lessIiESaIiEEPKSt3mapISsSsSA_ISsESaISt4pairIS2_SsEEE

SourceFile.o:

U _ZN4beau5posix14SubprocWrapperC1EiiiRKSsRKSt6vectorISsSaISsEERKSt3setIiSt4lessIiESaIiEEPKSt3mapISsSsSA_ISsESaISt4pairIKSsSsEEE

请注意，构造函数的两个错位名称不匹配!

我认为代码是符合标准的，因为它编译得很好，只是无法链接。代码大概 7 年左右没有改变，所有以前版本的英特尔编译器都可以正常工作。

为什么此代码在 Intel 2015 下有效，但在 2018 下无效？

Operating system: RHEL 7.4
GCC version: 4.8.5
libstdc++ version: 4.8.5

Intel compiler versions: 
2015.3.187 (Works!)
2018.1.163 (Fails to link!)

编辑: 这个问题似乎是某种竞争条件。当使用非常大的作业批处理(make -j30)进行编译时，我们还在 Intel 2015 编译器上注意到了这一点。问题出现了，经过进一步检查，我们发现确实，其中一个 .o 文件是使用符号的 KSs 版本而不是 IS2 版本编译的.在交换了一些脏话之后，我们删除了有问题的 .o 文件并再次编译，没有作业批处理(只是 make)，令我们惊讶的是，编译器这次生成了一个 不同的符号对于函数(IS2 版本)。这看起来非常奇怪，因为无论作业批号如何，编译器都应该始终生成相同的符号。不幸的是，这种行为不容易重复，因为我们做了一个 make clean，并再次以高作业批处理号运行，结果发现它在那个时候起作用了。

Answer 1

对不起，这实际上不是一个答案，只是一个评论，但我无法将其放入评论框中。

如果您分析这两个错位名称，您会发现它们只有一个片段不同:KSs与 S2_ . KSs表示 std::string const (或者，更准确地说，std::basic_string<char, std::char_traits<char>, std::allocator<char> > const)。 S2_是对前面遇到的名称的第 4 个可替换组件的压缩引用，实际上是相同的类型。看起来 GNU 修改方案在这件事上是模棱两可的，因为它没有规定在哪里使用或不使用压缩引用，而只是将它们描述为一个可用的选项。

但是，如果编译器没有以一致的方式破坏名称，因为它破坏了链接合法代码，这似乎是一个错误。您应该报告编译器的错误。