Linking Dylibs in Kexts?

Question

I\'ve written a kext for OS X that implements a USB-based framebuffer using (IOKit) libusb and jpeglib. Both of those are dylibs, and for some reason they won\'t link properly i

Answer 1

I'm afraid kexts aren't strictly dynamically linked themselves (they're loaded at runtime, but their structure is static) and barring some heroic custom linker/loader effort you won't get a dylib to load into kernel space.

As far as I know, the point of libusb is to write USB drivers in user space. It's therefore not clear to me why you're building a kext (which will run in kernel space) in the first place. Is there some element of the device that can't be driven from userspace using libusb? If so, try to make a kext only for that component and put the rest of the driver in a userspace daemon.

If splitting between libusb and your kernel-only component won't work, you'll need to use the kernel-space IOKit USB API in your kext. You can probably find a JPEG library that will compile statically, and which can be used in a kext (though not having a full libc will be an issue), but I strongly suspect you don't actually want to do this - JPEG (de)compression seems like it should be done in user space.

I get the impression you don't really need to deal with building your own kext at all - create a command-line (or GUI) app, link libusb and jpeglib to it, and do it all in user space. If you want it to go into the background, use the usual fork() method to daemonise your process, using a pipe, socket or other IPC to communicate with consumers of your driver. If you can somehow avoid writing a single line of kernel code, I'd strongly recommend sticking to user space. Debugging kernel code is a massive pain, and the more complex the driver, the worse it gets (I'd consider JPEG de/compression to be complex).

As usual, more information would be useful, particularly on the parts I mention.