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(a)redhat.com> 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