我为 OS X 编写了一个 kext，它使用 (IOKit) libusb 和 jpeglib 实现了一个基于 USB 的帧缓冲区。这两个都是 dylib，由于某种原因，它们无法在 XCode 中正确链接，并且操作系统在尝试加载 kext 时不会解析依赖关系。
这一切的背景是三星制造了一个液晶相框，可以充当第二个显示器；唯一的问题是它不是 DisplayLink 或任何其他已知协议——仅限 Windows 的驱动程序会输出一个自定义标头，并且每个帧都被编码为 JPEG 并发送到设备。我的实现是为 OS X 做的，但我使用 libusb，因为它是一个帧缓冲设备，需要在启动时加载——我希望更多地处理驱动显示器而不是热插拔检测和 IOKit 的 USB 设备要求。
感谢您的帮助！你们太棒了。
【问题讨论】：
标签： xcode dylib iokit kernel-extension
恐怕 kexts 本身并没有严格动态链接（它们在运行时加载，但它们的结构是静态的）并且除非进行一些英勇的自定义链接器/加载器工作，否则您将无法将 dylib 加载到内核空间.
据我所知，libusb 的重点是在 user 空间中编写 USB 驱动程序。因此，我不清楚你为什么首先要构建一个 kext（它将在内核空间中运行）。是否有一些设备元素不能使用 libusb 从用户空间驱动？如果是这样，请尝试仅为该组件创建一个 kext，并将驱动程序的其余部分放在用户空间守护进程中。
如果在 libusb 和仅内核组件之间拆分不起作用，则需要在 kext 中使用内核空间 IOKit USB API。您可能会找到一个静态编译的 JPEG 库，并且可以在 kext 中使用（尽管没有完整的 libc 将是一个问题），但我强烈怀疑您实际上并不想这样做 - JPEG（de ）压缩似乎应该在用户空间中完成。
我的印象是你根本不需要处理构建自己的 kext - 创建一个命令行（或 GUI）应用程序，将 libusb 和 jpeglib 链接到它，然后在用户空间中完成所有操作。如果您希望它进入后台，请使用通常的 fork() 方法来守护您的进程，使用管道、套接字或其他 IPC 与驱动程序的使用者进行通信。如果您能以某种方式避免编写一行内核代码，我强烈建议您坚持使用用户空间。调试内核代码是一件非常痛苦的事情，而且驱动程序越复杂，情况就越糟糕（我认为 JPEG 解/压缩很复杂）。
像往常一样，更多信息会很有用，尤其是关于我提到的部分。
【讨论】：