Justin, No problem, I appreciate you even responding/attempting. I'll cross-post this onto libvirt-dev then. 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 On Fri, Oct 8, 2010 at 10:59 AM, Justin Clift <jclift@xxxxxxxxxx> wrote: > On 10/09/2010 04:11 AM, Mitchell Hashimoto wrote: >> >> Justin, >> >> Yep: >> >> ~ → nm /usr/local/lib/libvirt.dylib | grep Thread >> 00000000001aec20 d _virTLSThreadImpl >> 0000000000011fd0 T _virThreadInitialize >> 0000000000012000 T _virThreadLocalGet >> 0000000000012010 T _virThreadLocalInit >> 0000000000011ff0 T _virThreadLocalSet >> 0000000000011fe0 T _virThreadOnExit >> >> And here is the output when running the test ruby file with >> DYLD_PRINT_LIBRARIES on, gisted since its quite long, but you can see >> libvirt in it prior to running the Ruby FFI code: >> >> https://gist.github.com/e90831db740cb0bff563 >> >> Any ideas? > > Unfortunately no. This is seriously past my depth of knowledge atm. :( > > Probably best to ask on the libvirt developers mailing list, as one of > the guys there (maybe Eric Blake or Chris Lalancette) might have ideas > about what's wrong. > > Hmmm, I wonder if it's a 32-bit vs 64-bit thing? Maybe the libvirt > package should be installed as a "universal binary"? I'm not sure > how to update it for that though. Kind of new to OSX. :/ > > >> Mitchell > >
