目前，我正在开发一个为嵌入式Linux应用程序提供功能的共享库。 该库可以在包含该特定功能的可移植逻辑的部分和特定于平台的运行时支持部分之间进行彻底划分。
我的第一反应是将它分成两个独立的共享库，如下所示：
programA＆lt; - libA.so＆lt; - libB.so
其中libB.so导出要在libA.so和libA.so中使用的符号导出要在programA中使用的符号。
我们的想法是，我们可以修复任一库中的错误，并简单地为客户提供更新的库以进行交换。我还想利用libB.so，如果我们要提供一个单独的libX.so，为programX提供不同的功能。
这个方案只是在崩溃时在运行时中断。
仔细检查一下，崩溃是由libB.so试图访问libA.so上未初始化的libc.so符号引起的。至少可以说，它首先尝试在那里找到它们，因为显然libB.so没有与libA.so联系起来。
我通过剥离libA中实际上不属于programA接口的任何符号解决了这个问题，而这正是我计划要做的事情。
然而，这个解决方案对我来说似乎并不是很干净，因为例如，如果programA开发人员决定用我们自己的另一个库包装我们的库（它将再次链接到libc），它将会破坏。
我想知道是否有正确的方法来执行此操作，或者我们是否应该坚持使用.so甚至切换到静态库。
注意：我们当前正在设置LD_LIBRARY_PATH以包含我们特定的库路径（如果重要）（例如，用于链接顺序）。