如何重新打包gnu gcc标准库stdc++；，海合会,海合会?？

在不修改和重新编译gnu gcc和stdc++库构建的情况下，我需要能够使用不同的嵌入式soname复制这些库的动态加载版本

我认为我会很聪明，使用可用的静态版本，并用如下内容重新打包：

ld-E-shared-static“-lstdc++”-lgcc-lgcc_eh-o librepackaged_标准。因此

librepacked_standard.so已创建，没有警告或错误，但ldd报告其不是动态库，readelf仅报告以下基本符号：

Symbol table '.symtab' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000201000     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
     2: 0000000000201000     0 NOTYPE  GLOBAL DEFAULT  ABS _edata
     3: 0000000000201000     0 NOTYPE  GLOBAL DEFAULT  ABS _end

我不确定为什么ld没有引入所有静态定义的符号。我也不知道是否有任何其他特殊的参数，我需要给它的工作

另一种选择是，如果有一种已知的跨平台方法，可以简单地更改嵌入在原始elf库中的soname。我目前只关心elf格式的二进制文件。我对编写自己的工具来更改现有二进制文件中的.soname不感兴趣

更新： 没有编译符号的原因是

ld

处理静态二进制文件的方式不同于.o文件。默认情况下，它不会从.a文件导入任何符号，除非链接行上的另一个库需要这些符号。我通过提供--whole archive选项修复了这个问题

然而，这给了我另一个错误，

在创建共享对象时，不能使用针对

\u ZSt12\u S\u first\u one'的重新定位R\u X86\u 64\u 32S；使用-fPIC

和

重新编译无法读取符号：错误值`它们都来自bitset.o存档中的libstdc++.a。因此，我不能只是将.a重新编译到动态库中，因为默认情况下，GNU GCC编译不会使用PIC选项编译用于静态库的对象文件

这让我不得不找到一个elf工具，或者重新编译GNU GCC，并对其构建进行修改

正如其中一个答案所述，许可证问题可能是这些方法中的一个问题。我最好的回答是，我们需要改变我们的需求，并找到一个不同的解决方案，不涉及以任何方式改变或重新打包GCC标准库

-static

可能会取消共享的

-shared

通常，您会从静态库中提取对象文件，然后将这些对象文件打包到共享库中，这依赖于PIC（位置独立代码）的通用性，以便静态库中的对象可以安全地转换为共享库。你可能不需要那个提取步骤，但我怀疑

您可能需要考虑是否符合许可条款和条件

---

没有符号被编译到共享库中的原因是

ld

处理静态二进制文件的方式不同于.o文件。默认情况下，它不会从.a文件导入任何符号，除非链接行上的另一个库需要这些符号。这个问题的答案是使用--whole archive选项并直接链接.a文件

但是，要使其工作，静态归档中包含的.o文件需要在编译时使用-fPIC选项进行编译。但是，用于静态库的对象文件不会在可用的静态库中使用该选项进行编译

因此，改变SONAME的解决方案是使用ELF二进制实用程序或重新构建GNU GCC，修改后使用不同的SONAME

---

由于在这种情况下存在许可问题，因此任何解决方案都不适用于该项目，因为它不是开源的，我们不希望要求为我们的所有平台重新发布GNU GCC的修改源代码版本

ld手册页状态为-static:不链接共享库。您可以在命令行上多次使用此选项：它会影响库搜索它后面的-l选项。此选项可与-shared一起使用。这样做意味着正在创建一个共享库，但库的所有外部引用都必须通过从静态库中提取条目来解决。在许可方面，这是向我提出要求的人提出的一个很好的观点。我试图说服他们，最好的选择是要求在受支持的平台上安装stdc++库包的最低版本，这是软件的常见做法。