[libvirt-users] Mac OS X: dyld: lazy symbol binding failed
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. Thanks, Mitchell
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
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. :) Thanks a lot for the homebrew recipe, saved me some work there. Best, Mitchell On Fri, Oct 8, 2010 at 12:35 AM, Justin Clift <jclift@redhat.com> wrote:
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
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? Mitchell On Fri, Oct 8, 2010 at 1:50 AM, Justin Clift <jclift@redhat.com> wrote:
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
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@redhat.com> 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
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
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@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
participants (2)
-
Justin Clift -
Mitchell Hashimoto