为什么库API+编译器ABI足以确保具有不同版本gcc的对象之间的兼容性

我遇到过一种情况，我可能想使用一个用一个版本的gcc编译的C++共享对象库，其中一些代码将用另一个版本gcc编译。特别是，我希望使用返回一些STL容器(如std::string和std::map)的方法。

gcc网站和许多旧的stackoverflow帖子(例如这里)讨论了这个问题。我目前的理解是

• 关于这个问题的大多数关注和帖子都是关于.so文件和.dll文件之间的交叉兼容性。由于编译器ABI不同，这是非常困难的。

• 对于使用不同版本的gcc编译的.so文件之间的交叉兼容性(至少对于gcc版本>=3.4)，您需要确保的是标准库API没有更改(如果更改了，则支持双重ABI)。

我的问题是关于这在机器级别上是如何工作的。似乎gcc可以更改实现std::string的头，即使库API没有更改，以便使其更高效或出于其他原因。如果是这样，那么两段不同的代码将使用两个不同的std::string头进行编译，并且基本上定义了两个具有相同名称的不同类。我们如何保证，当我们将std::string从使用一个标头的代码传递到使用另一标头的代码时，对象不会以某种方式被损坏或误读？

例如，假设我有以下文件：

// File a.h:
#ifndef FILE_A
#define FILE_A
#include <string>
class X {
public:
std::string f();
};
#endif  // FILE_A

// File a.cpp:
#include "a.h"
std::string X::f() {
return "hello world";
}

// File b.cpp:
#include <iostream>
#include <string>
#include "a.h"
int main() {
std::string x = X().f();
std::cout << x << std::endl;
}

(这里X类的唯一目的是在测试如何工作时，向共享对象库中引入更多的名称篡改。)

现在我编译如下：

/path/to/gcc/version_a/bin/g++ -fPIC -shared a.cpp -o liba.so
/path/to/gcc/version_b/bin/g++ -L. -la -o b b.cpp

当我执行b时，那么b具有来自version_b中的标头的std::string的定义。但是X().f()生成的对象依赖于使用来自gcc的version_a的头的副本编译的机器代码。

我不太了解编译器、链接器和机器指令的底层机制。但在我看来，我们在这里打破了一条基本规则，即每次使用类时，类的定义都必须相同，否则，我们无法保证上面的场景会起作用。

编辑：我认为解决我困惑的主要方法是，"库API"在本文中的含义比我习惯的"API"一词的使用更为笼统。gcc文档似乎以一种非常模糊的方式表明，实现标准库的include文件的任何更改都可以被视为库API的更改。有关详细信息，请参阅对Mohan回答的评论中的讨论。