xcode - Linking Dylibs in Kexts? -

i've written kext os x implements usb-based framebuffer using (iokit) libusb , jpeglib. both of dylibs, , reason won't link in xcode, , os won't resolve dependencies when attempts load kext.

the background of whole thing samsung makes lcd picture frame can act second monitor; problem it's not displaylink or other known protocol -- windows-only driver spits out custom header , each frame encoded jpeg , sent device. implementation os x, used libusb since it's framebuffer device , needs loaded @ startup -- wanted deal more driving display hot-plug detection , iokit's usb device requirements.

thanks help! guys awesome.

i'm afraid kexts aren't strictly dynamically linked (they're loaded @ runtime, structure static) , barring heroic custom linker/loader effort won't dylib load kernel space.

as far know, point of libusb write usb drivers in user space. it's therefore not clear me why you're building kext (which run in kernel space) in first place. there element of device can't driven userspace using libusb? if so, try make kext component , put rest of driver in userspace daemon.

if splitting between libusb , kernel-only component won't work, you'll need use kernel-space iokit usb api in kext. can find jpeg library compile statically, , can used in kext (though not having full libc issue), suspect don't want - jpeg (de)compression seems should done in user space.

i impression don't need deal building own kext @ - create command-line (or gui) app, link libusb , jpeglib it, , in user space. if want go background, use usual fork() method daemonise process, using pipe, socket or other ipc communicate consumers of driver. if can somehow avoid writing single line of kernel code, i'd recommend sticking user space. debugging kernel code massive pain, , more complex driver, worse gets (i'd consider jpeg de/compression complex).

as usual, more information useful, particularly on parts mention.