c – 在使用与目标发行版不同的编译器构建时,处理库依赖项的常用方法是什么？

概述如果我们说你的项目是用一个版本的C编译器构建的,并且它的潜在目标系统提供了用另一个版本构建的共享库,那么这通常是如何接近的？特别是这是一个关于libstdc的问题. 当在同一个发行版中构建某些东西时(例如在Linux等上),它非常简单 – 一切都是用相同的编译器构建的.但是像Mozilla Firefox这样的项目如何运送二进制文件据称与许多潜在目标兼容？我知道一种方法是静态链接C依赖关系,这减少 如果我们说你的项目是用一个版本的C编译器构建的,并且它的潜在目标系统提供了用另一个版本构建的共享库,那么这通常是如何接近的？特别是这是一个关于libstdc的问题.

当在同一个发行版中构建某些东西时(例如在Linux等上),它非常简单 – 一切都是用相同的编译器构建的.但是像Mozilla firefox这样的项目如何运送二进制文件据称与许多潜在目标兼容？我知道一种方法是静态链接C依赖关系,这减少了ABI不兼容问题,并限制外部链接只限于几个C库,但是当我查看实际的firefox二进制文件时(来自Mozilal版本的linux x86_64),我看到了这个：

ldd firefox    linux-vdso.so.1 (0x00007fff561fc000)    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff868c9f000)    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff868a9b000)    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff868892000)    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff868587000)    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff868286000)    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff86806f000)    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff867cc6000)    /lib64/ld-linux-x86-64.so.2 (0x00007ff868ee8000)

这里firefox动态链接libstdc.那么它如何才能在不同版本的libstdc中正常工作,或者只是假设ABI兼容性就是这样呢？

解决方法 常见的方式……

>设计人员/开发人员决定使用哪些(共享)库.在这里,可以给出静态链接的选项( – >构建配置).
>设计人员还会选择是否以及如何在构建时和/或安装时和/或运行时验证已使用库的版本.
>为不同目标创建二进制包的打包程序通常会使用目标的工具链和库来编译二进制包.
>如果不同目标需要仅二进制分发,则打包程序需要提供一种方法来检查环境并在安装时使用库( – >安装程序).安装程序或应用程序本身可以检查使用哪个工具链来构建共享库,然后继续,中止错误或发出警告并提供继续.
>打包程序可以在程序包中提供一组二进制模块,安装程序将在安装时选择所需的二进制模块并与给定的目标和环境兼容.

它当然是lege artis,应该是避免任何假设的常用方法 – 并可选择将其留给用户忽略任何警告并试试运气.

总结

以上是内存溢出为你收集整理的c – 在使用与目标发行版不同的编译器构建时,处理库依赖项的常用方法是什么？全部内容，希望文章能够帮你解决c – 在使用与目标发行版不同的编译器构建时,处理库依赖项的常用方法是什么？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。