Justin, I don't. But I'm extremely interested in getting this working for Mac OS X so I'll look into this. A heavy session of Google, to the rescue! Let me know if you come up with anything. If you have any hints or if I find any, feel free to email me directly so we don't spam the ML. Thanks again for responding to this. Mitchell On Tue, Oct 12, 2010 at 5:36 AM, Justin Clift <jclift@xxxxxxxxxx> wrote: > On 10/09/2010 05:19 AM, Mitchell Hashimoto wrote: >> >> Justin, >> >> No problem, I appreciate you even responding/attempting. I'll >> cross-post this onto libvirt-dev then. > > Heh. They forwarded it to me internally, as I've "been doing stuff for > OSX". :/ > > One of them did point out that it's probably something to do with the > linker not exporting a symbol on MacOS X for some reason. > > By default (so I'm told), libvirt uses some kind of linker script to > do the linking at compile time, and the symbols it exports are in the > file <libvirt_source_dir>/src/libvirt_public.syms. > > It looks to be a plain text file of simple structure, but there's no > mention of the word "Thread" in it anywhere. > > Don't suppose you know much about linking scripts? :) > > (yeah, I'm reaching :>) > > >> As for the alternate FFI API, this is was due to a bug in a very early >> version of the Ruby FFI bridge. By default, all FFI libraries are now >> loaded using DynamicLibrary#open, as far as I know (I've contributed >> some to the project). I'll take a look again to make sure this is >> still the case. >> >> Thanks, >> Mitchell > >
