On 10/08/2010 06:00 PM, Mitchell Hashimoto wrote: > > I'm using the Ruby/FFI libvirt library and getting this consistently > on Mac OS X: > > ruby-1.9.2-p0>  FFI::Libvirt.virInitialize > dyld: lazy symbol binding failed: Symbol not found: _virThreadInitialize >   Referenced from: /usr/local/lib/libvirt.dylib >   Expected in: flat namespace > > dyld: Symbol not found: _virThreadInitialize >   Referenced from: /usr/local/lib/libvirt.dylib >   Expected in: flat namespace > > Trace/BPT trap > > I exported DYLD_PRINT_LIBRARIES and it shows that libvirt.dylib is > loaded in the process space, but the above still occurs. When I > statically link into a C program it works fine, however. Anyone have > any idea what could be causing this? > > If this doesn't get a response, I'll post it to the dev list, since > its perhaps relevant to them as well. Hi Mitchell, Which build of libvirt do you have on the OSX box? Asking because some work has been happening recently to get libvirt into the Homebrew packaging (on OSX). The version added yesterday (0.8.4-6) is the latest one, so I'm thinking it might be worth trying that if you're using an older version? Regards and best wishes, Justin Clift

On 10/08/2010 07:36 PM, Mitchell Hashimoto wrote: > > Justin, > > I saw your commit into homebrew and I am actually trying that. Like I > said, statically linking it to a test C program I wrote worked fine, > but working over FFI and dynamically loading it failed with the quoted > error message. I'm unsure how to proceed at this point. :) No worries.  Does "_virThreadInitialize" exist in the dynamic library on your system?  $ nm /usr/local/lib/libvirt.dylib | grep Thread  00000000001a9c40 d _virTLSThreadImpl  00000000000125d0 T _virThreadInitialize  0000000000012600 T _virThreadLocalGet  0000000000012610 T _virThreadLocalInit  00000000000125f0 T _virThreadLocalSet  00000000000125e0 T _virThreadOnExit  $ Guessing it probably does, but figured it's worth checking. :) Regards and best wishes, Justin Clift

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

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