Nic*_* P. 7 linker objective-c static-libraries static-linking
我正在尝试找到打包静态库的最佳方法(让我们称之为Lib1),其中包含一个可选类(比如ClassA),它本身需要第二个静态库(Lib2).换句话说,只有在项目代码中引用ClassA时才需要Lib2.事情似乎工作正常,除非Lib1用于不使用ClassA的项目(因此不包括Lib2),但需要-ObjC链接器标志(因为其他项目依赖项,而不是我的).
我正在尝试为以下三种情况提出一个简单的解决方案:
1)项目包括我的静态lib,不使用可选类,不指定-ObjC标志
2)项目包括我的静态库,不是使用可选类,但需要-ObjC标志
3)项目包括我的静态lib +第二个静态库,而DOES使用可选类(此时我们不关心-ObjC标志)
是否有一个链接器标志从最终项目应用程序中删除我的可选类,以便它不需要第二个静态库？我想我的其他选择是发布我的静态库的多个版本,一个包含选项类(标准选项),一个不包含(替代,对于具有-ObjC要求的项目),或者可能提供存根文件,提供第二个静态库所需的所有类的空实现？这似乎可能是静态库世界中的常见问题...这种情况是否有最佳实践？
谢谢!
1)建议我的-ObjC用户使用-force_load.(感谢Rob!)
2)对于不能做1的用户,我将使用不包含ClassA的备用版本
最佳实践始终是将所有静态库所需的最终二进制链接.您永远不应将一个静态库捆绑到另一个静态库 绝对不要将一个众所周知的(即开源)静态库捆绑到您发布的静态库中.这可能会给最终消费者带来令人难以置信的麻烦,因为他们可以使用相同代码的多个版本.追踪可能来自此的错误是非常困难的.如果他们很幸运,他们只会遇到令人困惑的编译器错误.如果它们运气不好,它们的代码将以不可预测的方式运行并随机崩溃.
分别发送所有静态库.告诉您的客户他们需要链接哪些链接以进行各种配置.试图避免这种情况只会让他们的生活变得困难.
其他一些可能有用的讨论:
-ObjC标志应该完全阻止自动剥离ClassA,无论是否使用(有关详细信息,请参见TN1490).
如果ClassA从未使用过,除非在某些情况下并且您想节省空间,您应该移动ClassA到自己的静态库中.或者用于#ifdef有条件地编译它.
或者,您可以删除该-ObjC标志并使用-force_load单独加载任何仅类别编译单元(这-ObjC是用于解决的问题).
| 归档时间： |
|
| 查看次数： |
3602 次 |
| 最近记录： |