Re: [libvirt] Initial working Mac OS X libvirt client build
On Thu, Oct 21, 2010 at 11:18 PM, Ruben Kerkhof ru...@rubenkerkhof.com wrote: I thought I'd give it a try, to see how far I get on Leopard (10.5). From what I know following this list, I don't think anyone has ever tried to compile for Leopard (10.5) and has focussed exclusively on Snow Leopard (10.6), so there very well may be errors during compilation/linking. I'll wait for you to try the new formula but if that errors as well then I may have to spin up a leopard VM to play around see if I can figure out what is going on there. Mitchell -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Mac OS X: dyld: lazy symbol binding failed
All, With a few small patches (to remove documentation generation, thanks to Justin) to my local git checkout, I was finally able to make dist and test the resulting distribution. The result is that this worked great on my Mac as well as another Mac I have that was having trouble. I think this strongly supports the argument that the issue is that the libvirt build server autotools versions are out of date which is causing an issue for some reason on Mac. My autotools versions follow, for reference: Autoconf: 2.68 Automake: 1.11.1 Libtool: 2.4 For reference, or if anyone has a Mac and wants to try, I've uploaded my distribution here: http://mitchellh.github.com/libvirt/libvirt-0.8.4.tar.gz Is this enough evidence in favor of build tool versions? Would anyone like me to try anything else? Thanks, Mitchell On Thu, Oct 14, 2010 at 1:28 PM, Mitchell Hashimoto mitchell.hashim...@gmail.com wrote: Eric, First, here is the output from diff -c: https://gist.github.com/7d8c32849e4d72be5368 I ran `automake --version` and I have 1.11.1 And the 1.9.6 automake is from the libvirt build servers, not any of my machines. I was comparing the ./configure output from the snapshot with when I run autogen.sh myself. I'm not sure about the other points you brought up. I just ran the typical commands that README-hacking says to. Mitchell On Thu, Oct 14, 2010 at 12:44 PM, Eric Blake ebl...@redhat.com wrote: On 10/14/2010 01:06 PM, Mitchell Hashimoto wrote: Daniel, Thanks for your response, I appreciate it. The `grep` on the two Makefiles is equivalent. I've uploaded a diff of the two Makefiles here: https://gist.github.com/da0e93a335be6a3a637b Let me know if you want me to upload the actual Makefiles as well, since I can do that. Can you provide a context diff (diff -u or diff -c) rather than an ed-script diff? Context can be essential in a review. At any rate: # Makefile.in generated by automake 1.9.6 from Makefile.am. --- # Makefile.in generated by automake 1.11.1 from Makefile.am. Is this stock automake 1.9.6, or does it have a distro patch to fix CVE-2009-4029? Using an older automake may be the root cause of remaining problems, if we are relying on a feature that only automake 1.10 or 1.11 provides. What is 'automake --version' for you, and did you generate the tarballs, or is the automake 1.9.6 on someone else's machine? $(top_srcdir)/m4/nls.m4 $(top_srcdir)/m4/po.m4 \ $(top_srcdir)/m4/progtest.m4 $(top_srcdir)/m4/size_max.m4 \ $(top_srcdir)/m4/wchar_t.m4 $(top_srcdir)/m4/wint_t.m4 \ $(top_srcdir)/m4/xsize.m4 $(top_srcdir)/acinclude.m4 \ $(top_srcdir)/configure.ac --- $(top_srcdir)/m4/libtool.m4 $(top_srcdir)/m4/ltoptions.m4 \ $(top_srcdir)/m4/ltsugar.m4 $(top_srcdir)/m4/ltversion.m4 \ $(top_srcdir)/m4/lt~obsolete.m4 $(top_srcdir)/m4/nls.m4 \ $(top_srcdir)/m4/po.m4 $(top_srcdir)/m4/progtest.m4 \ $(top_srcdir)/m4/size_max.m4 $(top_srcdir)/m4/wchar_t.m4 \ $(top_srcdir)/m4/wint_t.m4 $(top_srcdir)/m4/xsize.m4 \ $(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac Why the difference in which libtool .m4 files are provided? configure.lineno configure.status.lineno --- configure.lineno config.status.lineno There's no such file as configure.status.lineno; but that's attributable to a bug in the older automake that has since been fixed. I've stopped looking at this point. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Mac OS X: dyld: lazy symbol binding failed
Daniel, Thanks for your response, I appreciate it. The `grep` on the two Makefiles is equivalent. I've uploaded a diff of the two Makefiles here: https://gist.github.com/da0e93a335be6a3a637b Let me know if you want me to upload the actual Makefiles as well, since I can do that. Also the src/libvirt.syms file is the same in both cases. Hope this helps! Let me know if there is anything else I can do to assist you. Mitchell On Thu, Oct 14, 2010 at 6:44 AM, Daniel P. Berrange berra...@redhat.com wrote: On Tue, Oct 12, 2010 at 02:56:31PM -0700, Mitchell Hashimoto wrote: I've been working with Justin, and we've been making some progress. However, I have another question for this list. As a follow-up to this, I realized that when I download the snapshots and just ./configure; make; make install then I get the lazy binding issue. However, if I go through the entire autogen process: ./autogen.sh make make install Do you see a difference when ou run # grep VERSION_SCRIPT_FLAGS Makefile VERSION_SCRIPT_FLAGS = -Wl,--version-script= between the plain 'configure' case, and the full autogen.sh case ? Also, does the src/libvirt.syms look any different in either case ? Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Mac OS X: dyld: lazy symbol binding failed
Eric, First, here is the output from diff -c: https://gist.github.com/7d8c32849e4d72be5368 I ran `automake --version` and I have 1.11.1 And the 1.9.6 automake is from the libvirt build servers, not any of my machines. I was comparing the ./configure output from the snapshot with when I run autogen.sh myself. I'm not sure about the other points you brought up. I just ran the typical commands that README-hacking says to. Mitchell On Thu, Oct 14, 2010 at 12:44 PM, Eric Blake ebl...@redhat.com wrote: On 10/14/2010 01:06 PM, Mitchell Hashimoto wrote: Daniel, Thanks for your response, I appreciate it. The `grep` on the two Makefiles is equivalent. I've uploaded a diff of the two Makefiles here: https://gist.github.com/da0e93a335be6a3a637b Let me know if you want me to upload the actual Makefiles as well, since I can do that. Can you provide a context diff (diff -u or diff -c) rather than an ed-script diff? Context can be essential in a review. At any rate: # Makefile.in generated by automake 1.9.6 from Makefile.am. --- # Makefile.in generated by automake 1.11.1 from Makefile.am. Is this stock automake 1.9.6, or does it have a distro patch to fix CVE-2009-4029? Using an older automake may be the root cause of remaining problems, if we are relying on a feature that only automake 1.10 or 1.11 provides. What is 'automake --version' for you, and did you generate the tarballs, or is the automake 1.9.6 on someone else's machine? $(top_srcdir)/m4/nls.m4 $(top_srcdir)/m4/po.m4 \ $(top_srcdir)/m4/progtest.m4 $(top_srcdir)/m4/size_max.m4 \ $(top_srcdir)/m4/wchar_t.m4 $(top_srcdir)/m4/wint_t.m4 \ $(top_srcdir)/m4/xsize.m4 $(top_srcdir)/acinclude.m4 \ $(top_srcdir)/configure.ac --- $(top_srcdir)/m4/libtool.m4 $(top_srcdir)/m4/ltoptions.m4 \ $(top_srcdir)/m4/ltsugar.m4 $(top_srcdir)/m4/ltversion.m4 \ $(top_srcdir)/m4/lt~obsolete.m4 $(top_srcdir)/m4/nls.m4 \ $(top_srcdir)/m4/po.m4 $(top_srcdir)/m4/progtest.m4 \ $(top_srcdir)/m4/size_max.m4 $(top_srcdir)/m4/wchar_t.m4 \ $(top_srcdir)/m4/wint_t.m4 $(top_srcdir)/m4/xsize.m4 \ $(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac Why the difference in which libtool .m4 files are provided? configure.lineno configure.status.lineno --- configure.lineno config.status.lineno There's no such file as configure.status.lineno; but that's attributable to a bug in the older automake that has since been fixed. I've stopped looking at this point. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Mac OS X: dyld: lazy symbol binding failed
Eric, I've been getting this error lately from git (happening during `make`): make[1]: *** No rule to make target `todo.pl', needed by `todo.html.in'. Stop. make: *** [distdir] Error 1 I haven't taken any time to look at it, but its caused by the documentation task, obviously. I've been getting around this during compile time with just doing make install which skips the doc task. This is preventing me from testing my `make dist` tarball. Mitchell On Tue, Oct 12, 2010 at 3:04 PM, Eric Blake ebl...@redhat.com wrote: On 10/12/2010 03:56 PM, Mitchell Hashimoto wrote: I've been working with Justin, and we've been making some progress. However, I have another question for this list. As a follow-up to this, I realized that when I download the snapshots and just ./configure; make; make install then I get the lazy binding issue. However, if I go through the entire autogen process: ./autogen.sh make make install Then this issue goes away. Could this be indicative of a bug in the autotools input perhaps on generating the packages on machines which aren't Macs? How do I test the packaging myself (on a Mac) so that I can verify this theory? Not ringing any bells for me. What if you do: ./autogen.sh make make dist then expand that tarball to another directory, run ./configure and make, and compare the git tree with the tarball you just created? Also, how does the snapshot compare to your tarball? Are you using git to create the snapshots (in which case I have no idea how the .gnulib submodule is being handled, if at all), or are they made from some 'make dist' cron job? -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Mac OS X: dyld: lazy symbol binding failed
Hi, This is a cross-post from libvirt-users since there didn't seem to be anyone there familiar with what is going on and this is a dev issue as well. 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? See this archive if you'd like to catch up on what was said in libvirt-users (its not a long thread): https://www.redhat.com/archives/libvirt-users/2010-October/msg00050.html Thanks, Mitchell -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Use SED variable for `sed` binary in src/Makefile
Hi, I've been trying to get libvirt (client) to cleanly/easily compile on BSD-based systems (in this case OS X). ./configure runs fine but the make caused an error with `sed` since BSD sed was reporting some sort of regex error. I realized that the SED variable was populated with gsed which worked properly. This made the make continue (failed again later, will address that when I can). This is my first contribution to a C-based project and I don't have much experience with autotools other than using them as a consumer. Let me know if anything can be improved. Thank you, Mitchell 0001-Use-SED-variable-for-sed-binary-in-src-Makefile.patch Description: Binary data -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Use SED variable for `sed` binary in src/Makefile
Hm, the patch attached as binary data. Here is the attached patch as text. Apologies about that: --- src/Makefile.am |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index b321657..118c329 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1029,14 +1029,14 @@ libvirt.syms: libvirt_public.syms $(USED_SYM_FILES) libvirt.def: libvirt.syms $(AM_V_GEN)rm -f -- $...@-tmp $@ ; \ printf 'EXPORTS\n' $...@-tmp \ - sed -e '/^$$/d; /#/d; /:/d; /\}/d; /\*/d; /LIBVIRT_/d; s/[ \t]*\(.*\)\;/\1/g' $^ $...@-tmp \ + $(SED) -e '/^$$/d; /#/d; /:/d; /\}/d; /\*/d; /LIBVIRT_/d; s/[ \t]*\(.*\)\;/\1/g' $^ $...@-tmp \ chmod a-w $...@-tmp \ mv $...@-tmp libvirt.def libvirt_qemu.def: $(srcdir)/libvirt_qemu.syms $(AM_V_GEN)rm -f -- $...@-tmp $@ ; \ printf 'EXPORTS\n' $...@-tmp \ - sed -e '/^$$/d; /#/d; /:/d; /\}/d; /\*/d; /LIBVIRT_/d; s/[ \t]*\(.*\)\;/\1/g' $^ $...@-tmp \ + $(SED) -e '/^$$/d; /#/d; /:/d; /\}/d; /\*/d; /LIBVIRT_/d; s/[ \t]*\(.*\)\;/\1/g' $^ $...@-tmp \ chmod a-w $...@-tmp \ mv $...@-tmp libvirt_qemu.def -- 1.7.2.2 On Wed, Sep 8, 2010 at 11:39 PM, Mitchell Hashimoto mitchell.hashim...@gmail.com wrote: Hi, I've been trying to get libvirt (client) to cleanly/easily compile on BSD-based systems (in this case OS X). ./configure runs fine but the make caused an error with `sed` since BSD sed was reporting some sort of regex error. I realized that the SED variable was populated with gsed which worked properly. This made the make continue (failed again later, will address that when I can). This is my first contribution to a C-based project and I don't have much experience with autotools other than using them as a consumer. Let me know if anything can be improved. Thank you, Mitchell -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
