librelist archives

Mac OS X: dyld: lazy symbol binding failed

From:

Justin Clift

Date:

2010-10-12 @ 20:21

Hi all,

Out of curiosity, does anyone have any idea what may be causing the
below error, where attempting to compile with the recently added libvirt
formula's library is failing?  (with Ruby FFI it seems)

None of us in the libvirt team have enough OSX experience presently to
know what the cause might be, and doing an "nm" on the libvirt.dylib
file shows the symbol is there.

Kind of out of ideas, so looking for suggestions if anyone knows what
the cause might be, or things we should be looking at?

Regards and best wishes,

Justin Clift


-------- Original Message --------
Subject: [libvirt-users] Mac OS X: dyld: lazy symbol binding failed
Date: Fri, 8 Oct 2010 00:00:06 -0700
From: Mitchell Hashimoto <mitchell.hashimoto@gmail.com>
To: libvirt-users@redhat.com

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

_______________________________________________
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

> Out of curiosity, does anyone have any idea what may be causing the
> below error, where attempting to compile with the recently added libvirt
> formula's library is failing?  (with Ruby FFI it seems)
> 
> None of us in the libvirt team have enough OSX experience presently to
> know what the cause might be, and doing an "nm" on the libvirt.dylib
> file shows the symbol is there.
> 
> Kind of out of ideas, so looking for suggestions if anyone knows what
> the cause might be, or things we should be looking at?

This might be a 32-bit vs 64-bit problem, if you're using the
preinstalled Ruby.  I just tried this using Homebrew's libvirt and ruby,
and I didn't get the link error.  To test this, you can force the
libvirt Ruby gem to build 64-bit, by defining

  ARCHFLAGS="-arch x86_64"

when you build the gem.

(It might also work to add ENV.universal_binary to the libvirt formula,
to make it compile a universal binary, though I think most homebrew
formulae avoid that if possible.)

cheers
–doug

—
Douglas Creager
RedJack, LLC
<dcreager@dcreager.net>

On 10/13/2010 08:35 AM, Douglas Creager wrote:
<snip>
> This might be a 32-bit vs 64-bit problem, if you're using the
> preinstalled Ruby.  I just tried this using Homebrew's libvirt and ruby,
> and I didn't get the link error.  To test this, you can force the
> libvirt Ruby gem to build 64-bit, by defining
> 
>   ARCHFLAGS="-arch x86_64"
> 
> when you build the gem.
> 
> (It might also work to add ENV.universal_binary to the libvirt formula,
> to make it compile a universal binary, though I think most homebrew
> formulae avoid that if possible.)

Just as a follow up, in case anyone else hits a similar thing at some
point.

The cause turned out to be a weird one.  The git source, when turned
into a tarball for distribution on RHEL 5.5 with "make dist" was broken
for _some people's OSX_.  Something to do with the version of autotools
on RHEL 5.5.

After updating the autotools (m4, autoconf, automake, libtool) to
recent versions (recompiled from Fedora 14 development) the generated
tarballs work.

Strange, but true. ;)