GNU 链接器：适应名称修改算法的更改

我正在尝试重新编译现有的 C++ 应用程序。 不幸的是，我必须依赖一个专有库，我只有一个预编译的静态存档。

我使用 g++ 版本 7.3.0 和 ld 版本 2.30。
无论它是用什么 GCC 版本编译的，它都是古老的。

头文件定义了方法：

class foo {
    int bar(int & i);
}

As nm lib.a显示，库存档包含相应的导出函数：

T bar__4fooRi

nm app.o显示了我最近使用不同类型的名称修饰的编译器：

U _ZN4foo9barERi

因此，链接器无法解析库提供的符号。

是否有任何选项可以选择名称修饰算法？
我可以引入地图或明确定义损坏的名称吗？

@Botje 的建议引导我编写这样的链接器脚本（PROVIDE 节中的空格很重要）：

EXTERN(bar__4fooRi);
PROVIDE(_ZN4foo9barERi = bar__4fooRi);

据我了解，这将考虑bar__4fooRi作为外部定义的符号（确实如此）。如果_ZN4foo9barERi被搜索但未定义，bar__4fooRi将取代它的位置。

我像这样从 GNU 工具链调用链接器（注意顺序 - 脚本需要位于依赖对象之后但定义库之前）：

g++ -o application application.o script.ld -lfoo

看来这可行。
至少在理论上是这样。
链接器现在考虑库的其他部分，这又依赖于其他无法解析的符号，包括（但不限于）__throw, __cp_pop_exception, and __builtin_delete。我现在不知道这些函数是在哪里定义的。 Joxean Koret 显示了以下位置的一些地点这篇博文 http://joxeankoret.com/blog/2012/11/14/patching-old-linux-binaries-to-work-with-recent-libc-versions/基于猜测（__builtin_new可能是malloc）——但我没那么自信。

这些发现使我得出这样的结论：该库也依赖于不同风格的异常处理，可能还依赖于内存管理。

EDIT:正如 @eukaryota 指出的，由于 ABI 更改，结果可能纯粹是学术性的，链接器脚本确实可以用于“别名”符号。这是一个完整的最小示例：

foo.h:

class Foo {
    public:
    int bar(int);
};

foo.cpp:

#include "foo.h"
int Foo::bar(int i) {
    return i+21;
}

主要.cpp：

class Foo {
    public:
    int baa(int); // use in-place "header" to simulate different name mangling algorithm
};

int main(int, char**) {
    Foo f;
    return f.baa(21);
}

脚本.ld：

EXTERN(_ZN3Foo3barEi);
PROVIDE(_ZN3Foo3baaEi = _ZN3Foo3barEi); /* declare "alias" */

构建过程：

g++ -o libfoo.o -c foo.c
ar rvs libfoo.a libfoo.o # simulate building a library
g++ -o app main.o -L. script.ld -lfoo

app已编译，可以执行并返回预期结果。