【问题标题】:Static vs. Shared library for sharing RTOS library with third party (so without source code)静态与共享库,用于与第三方共享 RTOS 库(因此没有源代码)
【发布时间】:2021-04-13 17:06:23
【问题描述】:

我知道有人问过类似的问题,但我仍然不清楚。

我为 Zephyr RTOS 编写了一个包含多个驱动程序和模块的库。现在我想与一家公司共享该库的一部分,但不作为源代码。想法是针对他们拥有的特定硬件编译相关源代码,然后共享。这样我可以控制它用于哪些产品,当然我不想与他们分享我的源代码。

起初我只是尝试共享一个静态库,但这并没有为他们编译。 Zephyr 的 CMake 扩展尚不支持共享库,因此我还没有尝试过。如果这是要走的路,我会潜入其中。

我有哪些选择?共享库与静态库(+ 目标文件?)?有什么推荐的?

更多信息 Zephyr 使用设备树。因此,我提供的驱动程序/模块是针对特定硬件目标编译的。我希望公司为我提供相关的硬件定义,以便我可以为他们提供适用于他们特定目标的驱动程序/模块的预编译库。这个库有时可能需要更新以包含错误修复/新功能。

由于二进制文件是使用应用程序 + 库编译的,静态库与共享库之间的权衡是什么?

【问题讨论】:

    标签: c linker shared-libraries static-libraries


    【解决方案1】:

    我认为共享库和头文件是要走的路。因为它们提供了优势。喜欢更小的二进制大小和更新的灵活性。你可以在这里找到一个很好的描述。 https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

    C++ 推荐使用共享库,因为它在 Linux 或类似 Linux 的系统上提供了灵活性 https://www.bogotobogo.com/cplusplus/libraries.php

    【讨论】:

    • 谢谢。固件是整体编译更新的,是不是意味着共享库的优势就不那么重要了?我认为它们无论如何都会组合成一个大的二进制文件?我的目标是为他们支付的特定硬件目标提供一个具有他们支付的特定功能的库。 Zephyr 使用设备树,在提供之前将其编译到库中。我需要共享库的灵活性吗?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-04-19
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多