[Libvir] libvirt on OS X Leopard 10.5.1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I spent the weekend attempting to get libvirt working on OS X Leopard 10.5.1. I was able to get it to compile, but not connect to libvirtd running on either my KVM or Xen servers. Here are the instructions for getting it to compile: 1. Download libvirt-0.4.0 from the mirrors. 2. Use macports to install pkgconfig and gnutls 3. Configure your source: ./configure --without-xen --without-qemu 4. Replace instances of 'hyper' in qemu/remote_protocol.x with 'long' and then follow the instructions on http://libvirt.org/windows.html to regen XDR structures. 5. Edit '/usr/include/net/if.h' and add the following include: #include <net/if_var.h> #include <sys/types.h> // // EDIT: akutz // #include <sys/socket.h> 6. Create a symlink for 'malloc.h' so the libvirt source can find it: sudo ln -s /usr/include/malloc/malloc.h /usr/include/malloc.h 7. Add a header to "src/remote_internal.c": // // EDIT: akutz // #include <sys/un.h> 8. The version-script parameter of ld is not portable to OS X. Edit 'src/Makefile': # # EDIT: akutz # #libvirt_la_LDFLAGS = -Wl,--version-script=$(srcdir)/ libvirt_sym.version \ # -version-info 4:0:4 \ # $(COVERAGE_CFLAGS:-f%=-Wc,-f%) \ libvirt_la_LDFLAGS = -Wl, \ -version-info 4:0:4 \ $(COVERAGE_CFLAGS:-f%=-Wc,-f%) \ 9. Replace the distribution copy of libread.dylib with the one from Macports or else you will get errors about missing symbols (thread starts here http://www.mail-archive.com/macports-dev@lists.macosforge.org/msg00729.html) : sudo mv /usr/lib/libreadline.dylib /usr/lib/libreadline.dylib.dist sudo ln -s /opt/local/lib/libreadline.dylib /usr/lib/libreadline.dylib 10. The sources should now build and install. At this point any attempt to connect to a remote host results in the thread dying and OS X catching the exception with the following report: <beginReport> Process: Python [57356] Path: /System/Library/Frameworks/Python.framework/Versions/ 2.5/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [59098] Date/Time: 2008-01-21 16:48:52.228 -0600 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004 Crashed Thread: 0 Thread 0 Crashed: 0 libvirt.0.dylib 0x00412911 remoteAuthenticate + 1345 (remote_internal.c:3062) 1 libvirt.0.dylib 0x00414869 doRemoteOpen + 3593 (remote_internal.c:753) 2 libvirt.0.dylib 0x00415499 remoteOpen + 137 (remote_internal.c:860) 3 libvirt.0.dylib 0x00401438 do_open + 392 (libvirt.c: 579) 4 libvirtmod.so 0x000c0e06 libvirt_virConnectOpen + 102 (libvirt-py.c:1026) 5 org.python.python 0x0018d826 PyEval_EvalFrameEx + 17116 6 org.python.python 0x0018da08 PyEval_EvalFrameEx + 17598 7 org.python.python 0x0018f47b PyEval_EvalCodeEx + 1638 8 org.python.python 0x0018f568 PyEval_EvalCode + 87 9 org.python.python 0x001a6a0c PyErr_Display + 1896 10 org.python.python 0x001a7036 PyRun_FileExFlags + 135 11 org.python.python 0x001a89a2 PyRun_SimpleFileExFlags + 421 12 org.python.python 0x001b3c23 Py_Main + 3095 13 org.python.pythonapp 0x00001fca 0x1000 + 4042 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x004123e1 ecx: 0xbfffe826 edx: 0x00000000 edi: 0x00000000 esi: 0xbfffe92c ebp: 0xbfffea48 esp: 0xbfffe860 ss: 0x0000001f efl: 0x00010202 eip: 0x00412911 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x00000004 Binary Images: 0x1000 - 0x1ffe org.python.pythonapp 2.5.0 (2.5.0a0) <a2ccf04a940c23b34c33d7fe108d773e> /System/Library/Frameworks/ Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python 0x49000 - 0x4bfff +libgpg-error.0.dylib ??? (???) /opt/local/ lib/libgpg-error.0.dylib 0xbb000 - 0xc2ff3 +libvirtmod.so ??? (???) <20dea38de64927c9e8b50a1fa240e067> /usr/local/lib/python2.5/site- packages/libvirtmod.so 0x118000 - 0x1e3ffb org.python.python 2.5 (2.5) <9786e5d8790a594bb7b3cdcf9a9d0b49> /System/Library/Frameworks/ Python.framework/Versions/2.5/Python 0x2f0000 - 0x2f7ff3 +libintl.8.dylib ??? (???) /opt/local/lib/ libintl.8.dylib 0x400000 - 0x424fef +libvirt.0.dylib ??? (???) <70af9029fa4c7accc04377f0f65c53ae> /usr/local/lib/libvirt.0.dylib 0x43b000 - 0x49bfff +libgnutls.26.dylib ??? (???) /opt/local/lib/ libgnutls.26.dylib 0x4b5000 - 0x4c2fe2 +libtasn1.3.dylib ??? (???) /opt/local/lib/ libtasn1.3.dylib 0x4c7000 - 0x528ff3 +libgcrypt.11.dylib ??? (???) <76bad0ad90909bf99f422f8bbfd61124> /opt/local/lib/libgcrypt.11.dylib 0x540000 - 0x637ff0 +libiconv.2.dylib ??? (???) /opt/local/lib/ libiconv.2.dylib 0x644000 - 0x654ffd +libz.1.dylib ??? (???) /opt/local/lib/libz. 1.dylib 0x65f000 - 0x661ffc apop.so ??? (???) <8e5cbfa49bbed80ed34f03e008e3e086> /usr/lib/sasl2/apop.so 0x665000 - 0x67dfe2 dhx.so ??? (???) <0831cf2893deaa2b5525ea7bfda17404> /usr/lib/sasl2/dhx.so 0x68c000 - 0x694fff digestmd5WebDAV.so ??? (???) <42e13c06e037f02eee71a43324169f62> /usr/lib/sasl2/digestmd5WebDAV.so 0x698000 - 0x69afff libanonymous.2.so ??? (???) <161902c9ed78dce78b61125c7c155f0f> /usr/lib/sasl2/libanonymous.2.so 0x69e000 - 0x6a0ffc libcrammd5.2.so ??? (???) <c917c89eefddcfcacf48c939c3af12aa> /usr/lib/sasl2/libcrammd5.2.so 0x6a4000 - 0x6adffb libdigestmd5.2.so ??? (???) <c8595204acd0e7cb362b33d008693019> /usr/lib/sasl2/libdigestmd5.2.so 0x6b1000 - 0x6b5fff libgssapiv2.2.so ??? (???) <a47ee23249e7c36aee418a6e7fd3a502> /usr/lib/sasl2/libgssapiv2.2.so 0x6bb000 - 0x6bdffc login.so ??? (???) <03d28ec908a6ed9abee1b25fe87716ef> /usr/lib/sasl2/login.so 0x6c1000 - 0x6c8ffc libotp.2.so ??? (???) <0b7c8cd165835331c586e49465ef1186> /usr/lib/sasl2/libotp.2.so 0x6d2000 - 0x6d4ffc libplain.2.so ??? (???) <5992f1149ff6cc7fadafa2bfd4ecc00a> /usr/lib/sasl2/libplain.2.so 0x6d8000 - 0x6ddffc libpps.so ??? (???) <ae02d7b23951bddb4db705b2d632c6ac> /usr/lib/sasl2/libpps.so 0x6e3000 - 0x6e6fff mschapv2.so ??? (???) <8d5951f3d3a0565fd772ebec4d2054fb> /usr/lib/sasl2/mschapv2.so 0x6ea000 - 0x6ecffc shadow_auxprop.so ??? (???) <5137115453406a92cf514b65046a6b28> /usr/lib/sasl2/shadow_auxprop.so 0x6f2000 - 0x6f4ffd smb_lm.so ??? (???) <e9ad275441e15388bf580b1cdf55b430> /usr/lib/sasl2/smb_lm.so 0x6f8000 - 0x6faffc smb_nt.so ??? (???) <a7144a88919b4aea313caf6c4e86353a> /usr/lib/sasl2/smb_nt.so 0x6fe000 - 0x701ff0 smb_ntlmv2.so ??? (???) <ccfa6d0eafa992db95ad309e32c6d400> /usr/lib/sasl2/smb_ntlmv2.so 0x8fe00000 - 0x8fe2d883 dyld 95.3 (???) <81592e798780564b5d46b988f7ee1a6a> /usr/lib/dyld 0x90d29000 - 0x90e5bfe7 com.apple.CoreFoundation 6.5 (476) <8bfebc0dbad6fc33bea0fa00a1b9ec37> /System/Library/Frameworks/ CoreFoundation.framework/Versions/A/CoreFoundation 0x90e5c000 - 0x90e7aff3 com.apple.DirectoryService.Framework 3.5 (3.5) <899d8c9ee31b004a6ff73dab88982b1a> /System/Library/Frameworks/ DirectoryService.framework/Versions/A/DirectoryService 0x922a3000 - 0x92353fff edu.mit.Kerberos 6.0.11 (6.0.11) <33c25789baedcd70a7e24881775dd9ad> /System/Library/Frameworks/ Kerberos.framework/Versions/A/Kerberos 0x9244f000 - 0x924acffb libstdc++.6.dylib ??? (???) <04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib 0x92510000 - 0x926d9fef com.apple.security 5.0.1 (32736) <8c9eda0fcc1d8a571543025ac900715f> /System/Library/Frameworks/ Security.framework/Versions/A/Security 0x92f62000 - 0x92f80fff libresolv.9.dylib ??? (???) <54e6a08c2f108bdf5916fb483d51961b> /usr/lib/libresolv.9.dylib 0x93661000 - 0x9366fffd libz.1.dylib ??? (???) <5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib 0x936a2000 - 0x93783ff7 libxml2.2.dylib ??? (???) <450ec38b57fb46013847cce851001a2f> /usr/lib/libxml2.2.dylib 0x93d28000 - 0x93d2ffe9 libgcc_s.1.dylib ??? (???) <f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib 0x94a5b000 - 0x94b93ff7 libicucore.A.dylib ??? (???) <afcea652ff2ec36885b2c81c57d06d4c> /usr/lib/libicucore.A.dylib 0x95a7f000 - 0x95b5efff libobjc.A.dylib ??? (???) <5eda47fec2d0e7853b3506aa1fd2dafa> /usr/lib/libobjc.A.dylib 0x9631e000 - 0x963d0ffb libcrypto.0.9.7.dylib ??? (???) <330b0e48e67faffc8c22dfc069ca7a47> /usr/lib/libcrypto.0.9.7.dylib 0x9642c000 - 0x9643bfff libsasl2.2.dylib ??? (???) <b9e1ca0b6612e280b6cbea6df0eec5f6> /usr/lib/libsasl2.2.dylib 0x9643c000 - 0x96466fef libauto.dylib ??? (???) <d468bc4a8a69343f1748c293db1b57fb> /usr/lib/libauto.dylib 0x96d8c000 - 0x96d8dfef libmathCommon.A.dylib ??? (???) /usr/lib/ system/libmathCommon.A.dylib 0x96d9a000 - 0x96ef4fe3 libSystem.B.dylib ??? (???) <8ecc83dc0399be3946f7a46e88cf4bbb> /usr/lib/libSystem.B.dylib 0xfffe8000 - 0xfffebfff libobjc.A.dylib ??? (???) /usr/lib/ libobjc.A.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/ libSystem.B.dylib </beginReport> Anyway, hopefully someone on the list can make heads or tails of why this is not working on OS X. I sure would love to be able to use libvirt instead of xenapi. Thanks! - -- - -a -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlSG1Tg8lceyAqqQRAiD1AJ99NZC23AheQl36oGYU/mmjqILbtwCg07+i /TT0j27cGU7krDDMk+hVX/k= =P+Cg -----END PGP SIGNATURE-----
On Mon, Jan 21, 2008 at 04:50:29PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I spent the weekend attempting to get libvirt working on OS X Leopard 10.5.1. I was able to get it to compile, but not connect to libvirtd running on either my KVM or Xen servers. Here are the instructions for getting it to compile:
1. Download libvirt-0.4.0 from the mirrors.
2. Use macports to install pkgconfig and gnutls
3. Configure your source:
./configure --without-xen --without-qemu
4. Replace instances of 'hyper' in qemu/remote_protocol.x with 'long' and then follow the instructions on http://libvirt.org/windows.html to regen XDR structures.
This is going to fail big time. 'hyper' is 64-bit in size, where as long is 32-bit. Any RPC calls which user hyper will crash and burn if you make this change. What errors do you get if you don't make this change ? There may be better ways to provide compatability.
10. The sources should now build and install.
At this point any attempt to connect to a remote host results in the thread dying and OS X catching the exception with the following report:
<beginReport> Process: Python [57356] Path: /System/Library/Frameworks/Python.framework/Versions/ 2.5/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [59098]
Date/Time: 2008-01-21 16:48:52.228 -0600 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004 Crashed Thread: 0
Thread 0 Crashed: 0 libvirt.0.dylib 0x00412911 remoteAuthenticate + 1345 (remote_internal.c:3062)
There wre two bugs in the remoteAuthenticate method in libvirt 0.4.0 which can cause crashes. I'd recommend testing again with libvirt from the latest CVS checkout - its pretty likely that'll fix your problem. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ah, I knew hyper was 64-bit, but it has no definition on OS X. I thought that long on OS X 10.5.1 was 64 bits in width -- my mistake.
There wre two bugs in the remoteAuthenticate method in libvirt 0.4.0 which can cause crashes. I'd recommend testing again with libvirt from the latest CVS checkout - its pretty likely that'll fix your problem.
The funny thing is that I have all auth mechanisms turned off in libvirtd. But I can see how some of the library's init code may be failing. I did try to build the package from HEAD, but that failed. I will try again and report the errors. Thanks! - -- - -a On Jan 21, 2008, at 5:20 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 04:50:29PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I spent the weekend attempting to get libvirt working on OS X Leopard 10.5.1. I was able to get it to compile, but not connect to libvirtd running on either my KVM or Xen servers. Here are the instructions for getting it to compile:
1. Download libvirt-0.4.0 from the mirrors.
2. Use macports to install pkgconfig and gnutls
3. Configure your source:
./configure --without-xen --without-qemu
4. Replace instances of 'hyper' in qemu/remote_protocol.x with 'long' and then follow the instructions on http://libvirt.org/windows.html to regen XDR structures.
This is going to fail big time. 'hyper' is 64-bit in size, where as long is 32-bit. Any RPC calls which user hyper will crash and burn if you make this change.
What errors do you get if you don't make this change ? There may be better ways to provide compatability.
10. The sources should now build and install.
At this point any attempt to connect to a remote host results in the thread dying and OS X catching the exception with the following report:
<beginReport> Process: Python [57356] Path: /System/Library/Frameworks/Python.framework/ Versions/ 2.5/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [59098]
Date/Time: 2008-01-21 16:48:52.228 -0600 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004 Crashed Thread: 0
Thread 0 Crashed: 0 libvirt.0.dylib 0x00412911 remoteAuthenticate + 1345 (remote_internal.c:3062)
There wre two bugs in the remoteAuthenticate method in libvirt 0.4.0 which can cause crashes. I'd recommend testing again with libvirt from the latest CVS checkout - its pretty likely that'll fix your problem.
Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlSplTg8lceyAqqQRAtk7AKCGcGnPEKJIHYmOy28nNVKtq4k1qgCffMYd 1ReRbsHTUqtPODeBgcCKhHo= =86Kw -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Okay, the autogen.sh fails right off the bat. To get it working you have to edit it so that it checks the ld version with a '-V' instead of '--version' (OS X specific). Once you do that and run: ./autogen.sh --without-xen --without-qemu it trucks along nicely until: ./configure: line 35741: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35741: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)' Line 35721 of the generated configure script begins: PKG_PROG_PKG_CONFIG LIBXML_CONFIG="xml2-config" LIBXML_CFLAGS="" LIBXML_LIBS="" LIBXML_FOUND="no" # Check whether --with-libxml was given. if test "${with_libxml+set}" = set; then withval=$with_libxml; fi if test "z$with_libxml" = "zno" ; then { echo "$as_me:$LINENO: checking for libxml2 libraries >= $LIBXML_REQUIRED" >&5 echo $ECHO_N "checking for libxml2 libraries >= $LIBXML_REQUIRED... $ECHO_C" >&6; } { { echo "$as_me:$LINENO: error: libxml2 >= $LIBXML_REQUIRED is required for libvirt" >&5 echo "$as_me: error: libxml2 >= $LIBXML_REQUIRED is required for libvirt" >&2;} { (exit 1); exit 1; }; } elif test "z$with_libxml" = "z" -a "x$PKG_CONFIG" != "x" ; then PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes) if test "$LIBXML_FOUND" != "no" ; then PKG_CHECK_MODULES(LIBXML, libxml-2.0 >= $LIBXML_REQUIRED) fi fi Looks like some stand-in values are not getting replaced when the configure script is generated. Ideas? - -- - -a On Jan 21, 2008, at 5:27 PM, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ah, I knew hyper was 64-bit, but it has no definition on OS X. I thought that long on OS X 10.5.1 was 64 bits in width -- my mistake.
There wre two bugs in the remoteAuthenticate method in libvirt 0.4.0 which can cause crashes. I'd recommend testing again with libvirt from the latest CVS checkout - its pretty likely that'll fix your problem.
The funny thing is that I have all auth mechanisms turned off in libvirtd. But I can see how some of the library's init code may be failing. I did try to build the package from HEAD, but that failed. I will try again and report the errors.
Thanks!
- -- - -a
On Jan 21, 2008, at 5:20 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 04:50:29PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I spent the weekend attempting to get libvirt working on OS X Leopard 10.5.1. I was able to get it to compile, but not connect to libvirtd running on either my KVM or Xen servers. Here are the instructions for getting it to compile:
1. Download libvirt-0.4.0 from the mirrors.
2. Use macports to install pkgconfig and gnutls
3. Configure your source:
./configure --without-xen --without-qemu
4. Replace instances of 'hyper' in qemu/remote_protocol.x with 'long' and then follow the instructions on http://libvirt.org/ windows.html to regen XDR structures.
This is going to fail big time. 'hyper' is 64-bit in size, where as long is 32-bit. Any RPC calls which user hyper will crash and burn if you make this change.
What errors do you get if you don't make this change ? There may be better ways to provide compatability.
10. The sources should now build and install.
At this point any attempt to connect to a remote host results in the thread dying and OS X catching the exception with the following report:
<beginReport> Process: Python [57356] Path: /System/Library/Frameworks/Python.framework/ Versions/ 2.5/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [59098]
Date/Time: 2008-01-21 16:48:52.228 -0600 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004 Crashed Thread: 0
Thread 0 Crashed: 0 libvirt.0.dylib 0x00412911 remoteAuthenticate + 1345 (remote_internal.c:3062)
There wre two bugs in the remoteAuthenticate method in libvirt 0.4.0 which can cause crashes. I'd recommend testing again with libvirt from the latest CVS checkout - its pretty likely that'll fix your problem.
Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHlSplTg8lceyAqqQRAtk7AKCGcGnPEKJIHYmOy28nNVKtq4k1qgCffMYd 1ReRbsHTUqtPODeBgcCKhHo= =86Kw -----END PGP SIGNATURE-----
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlSuRTg8lceyAqqQRAgnOAKDeAAJoeVu+WOzM2W7fXbXpwgYZlACfa6ao 4+5tDMQEHSIetjA3CdC5O8w= =qb2c -----END PGP SIGNATURE-----
On Mon, Jan 21, 2008 at 05:32:33PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Okay, the autogen.sh fails right off the bat. To get it working you have to edit it so that it checks the ld version with a '-V' instead of '--version' (OS X specific). Once you do that and run:
./autogen.sh --without-xen --without-qemu
Running autogen.sh requires that you have all optional software installed and pkg-config files for them present. If you're missing any software then it is unlikely to work. Rather than running autogen.sh on Mac OS, I'd recommend running it on Linux and creating yourself a snapshot tar.gz. eg ./autogen.sh make dist This should give you a libvirt-0.4.0.tar.gz containing a snapshot of CVS, which you can the copy over to Mac OS & run configure normally as before. I would point you at the snapshot tar.gz here, but it appears to be not updated since September http://libvirt.org/downloads.html Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fails the same way on Linux (Ubuntu 7.10 Gutsy Gibbon - Server - x86_64): ./configure: line 35963: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35963: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)' Maybe the M4 parsing is incorrect and not replacing the values correctly? As I recall, M4 is a real pain. And, yes, both libxml2 and its headers are installed :( - -- - -a On Jan 21, 2008, at 5:39 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 05:32:33PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Okay, the autogen.sh fails right off the bat. To get it working you have to edit it so that it checks the ld version with a '-V' instead of '--version' (OS X specific). Once you do that and run:
./autogen.sh --without-xen --without-qemu
Running autogen.sh requires that you have all optional software installed and pkg-config files for them present. If you're missing any software then it is unlikely to work. Rather than running autogen.sh on Mac OS, I'd recommend running it on Linux and creating yourself a snapshot tar.gz.
eg
./autogen.sh make dist
This should give you a libvirt-0.4.0.tar.gz containing a snapshot of CVS, which you can the copy over to Mac OS & run configure normally as before.
I would point you at the snapshot tar.gz here, but it appears to be not updated since September
http://libvirt.org/downloads.html
Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlTGOTg8lceyAqqQRAiibAJ9uiRzWh/ViW7F5uCUazwtGjQFr1gCfe85I KDDk90xGvn6vNpng0TJ8UKo= =+XKu -----END PGP SIGNATURE-----
On Mon, Jan 21, 2008 at 05:58:06PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Fails the same way on Linux (Ubuntu 7.10 Gutsy Gibbon - Server - x86_64):
./configure: line 35963: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35963: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
Maybe the M4 parsing is incorrect and not replacing the values correctly? As I recall, M4 is a real pain.
And, yes, both libxml2 and its headers are installed :(
Also check that 'pkg-config' binary is installed and that you have a file /usr/share/aclocal/pkg.m4 Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was missing pkg-config. But the 'make dist' now fails: make[3]: Entering directory `/usr/local/src/libvirt/docs/examples/ python' make[3]: Leaving directory `/usr/local/src/libvirt/docs/examples/python' make[2]: Leaving directory `/usr/local/src/libvirt/docs/examples' make[2]: Entering directory `/usr/local/src/libvirt/docs/devhelp' Rebuilding devhelp files Rebuilding devhelp files Rebuilding devhelp files Rebuilding devhelp files cp: cannot stat `./libvirt.devhelp': No such file or directory make[2]: *** [distdir] Error 1 make[2]: Leaving directory `/usr/local/src/libvirt/docs/devhelp' make[1]: *** [distdir] Error 1 make[1]: Leaving directory `/usr/local/src/libvirt/docs' make: *** [distdir] Error 1 - -- - -a On Jan 21, 2008, at 6:02 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 05:58:06PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Fails the same way on Linux (Ubuntu 7.10 Gutsy Gibbon - Server - x86_64):
./configure: line 35963: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35963: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
Maybe the M4 parsing is incorrect and not replacing the values correctly? As I recall, M4 is a real pain.
And, yes, both libxml2 and its headers are installed :(
Also check that 'pkg-config' binary is installed and that you have a file /usr/share/aclocal/pkg.m4
Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlTW+Tg8lceyAqqQRArbxAJsHW52aNogk86/gKhapqotZLELX8ACfQjDp 0yRh+17IIFDUODJrrzsw++4= =TGch -----END PGP SIGNATURE-----
Schley Andrew Kutz <akutz@lostcreations.com> wrote:
I was missing pkg-config. But the 'make dist' now fails:
make[3]: Entering directory `/usr/local/src/libvirt/docs/examples/ python' make[3]: Leaving directory `/usr/local/src/libvirt/docs/examples/python' make[2]: Leaving directory `/usr/local/src/libvirt/docs/examples' make[2]: Entering directory `/usr/local/src/libvirt/docs/devhelp' Rebuilding devhelp files Rebuilding devhelp files Rebuilding devhelp files Rebuilding devhelp files cp: cannot stat `./libvirt.devhelp': No such file or directory
That's probably because configure did not find an xsltproc program, and without that, the Makefile.am rule in docs/devhelp/Makefile.am doesn't even try to create libvirt.devhelp, even though it's required for distribution. You can work around it by running "touch docs/devhelp/libvirt.devhelp". I suspect this hasn't come up before because everyone else running "make dist" already had xsltproc installed. There are a couple of other minor problems in the vicinity, so I'll propose a patch.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That was it, thanks! - -- - -a On Jan 22, 2008, at 6:33 AM, Jim Meyering wrote:
xsltproc
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHleMJTg8lceyAqqQRAoLkAJ9/gyb2fUaw2D/sKqwk9LNz943wiQCg5hEy gqeX9aMkbMUUO8jJ7mNIYvk= =vIA6 -----END PGP SIGNATURE-----
On Tue, Jan 22, 2008 at 12:02:49AM +0000, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 05:58:06PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Fails the same way on Linux (Ubuntu 7.10 Gutsy Gibbon - Server - x86_64):
./configure: line 35963: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35963: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
Maybe the M4 parsing is incorrect and not replacing the values correctly? As I recall, M4 is a real pain.
And, yes, both libxml2 and its headers are installed :(
Also check that 'pkg-config' binary is installed and that you have a file /usr/share/aclocal/pkg.m4
We have, on libvirt.org: xmlsoft:~ -> ls /usr/share/aclocal/pkg.m4 /usr/share/aclocal/pkg.m4 xmlsoft:~ -> pkg-config --version 0.15.0 xmlsoft:~ -> same behaviour, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Jan 21, 2008 at 11:39:35PM +0000, Daniel P. Berrange wrote:
I would point you at the snapshot tar.gz here, but it appears to be not updated since September
./configure: line 35987: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35987: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)' libvirt.org is a RHEL4 box, seems the pkgconfig requirements which were introduced break running autogen.sh , so no Makefile, make dist, and no snapshot apparently. I will try to investigate but I can't believe we managed to break detection for something as common as libxml2 *on xmlsoft.org itself*, the irony ... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, Jan 22, 2008 at 08:00:34AM -0500, Daniel Veillard wrote:
On Mon, Jan 21, 2008 at 11:39:35PM +0000, Daniel P. Berrange wrote:
I would point you at the snapshot tar.gz here, but it appears to be not updated since September
./configure: line 35987: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35987: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
libvirt.org is a RHEL4 box, seems the pkgconfig requirements which were introduced break running autogen.sh , so no Makefile, make dist, and no snapshot apparently. I will try to investigate but I can't believe we managed to break detection for something as common as libxml2 *on xmlsoft.org itself*, the irony ...
Upgrading pkg-config on the box this goes further but then gets stuck at: configure: error: conditional "HAVE_SASL" was never defined. Usually this means the macro was only invoked conditionally. trying to autogen with ./autogen.sh --prefix=/usr --without-depends --without-sasl I don't understand the problem, it seems AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) is set outside of any conditional block in configure.in And if I don't specify --without-sasl it breaks when looking for the library. I really don't see how to fix the dist snapshot build on RHEL4 Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, Jan 22, 2008 at 08:27:58AM -0500, Daniel Veillard wrote:
On Tue, Jan 22, 2008 at 08:00:34AM -0500, Daniel Veillard wrote:
On Mon, Jan 21, 2008 at 11:39:35PM +0000, Daniel P. Berrange wrote:
I would point you at the snapshot tar.gz here, but it appears to be not updated since September
./configure: line 35987: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35987: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
libvirt.org is a RHEL4 box, seems the pkgconfig requirements which were introduced break running autogen.sh , so no Makefile, make dist, and no snapshot apparently. I will try to investigate but I can't believe we managed to break detection for something as common as libxml2 *on xmlsoft.org itself*, the irony ...
Upgrading pkg-config on the box this goes further but then gets stuck at:
configure: error: conditional "HAVE_SASL" was never defined. Usually this means the macro was only invoked conditionally.
trying to autogen with ./autogen.sh --prefix=/usr --without-depends --without-sasl
I don't understand the problem, it seems AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) is set outside of any conditional block in configure.in And if I don't specify --without-sasl it breaks when looking for the library.
I really don't see how to fix the dist snapshot build on RHEL4
Ok, I'll fire up a RHEL4 guest and figure out the neccessary m4 craziness we need to fix this. The SASL stuff should really auto-enable/disable itself like all the other libs can. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Daniel Veillard <veillard@redhat.com> wrote:
On Tue, Jan 22, 2008 at 08:00:34AM -0500, Daniel Veillard wrote:
On Mon, Jan 21, 2008 at 11:39:35PM +0000, Daniel P. Berrange wrote:
I would point you at the snapshot tar.gz here, but it appears to be not updated since September
./configure: line 35987: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35987: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
libvirt.org is a RHEL4 box, seems the pkgconfig requirements which were introduced break running autogen.sh , so no Makefile, make dist, and no snapshot apparently. I will try to investigate but I can't believe we managed to break detection for something as common as libxml2 *on xmlsoft.org itself*, the irony ...
Upgrading pkg-config on the box this goes further but then gets stuck at:
configure: error: conditional "HAVE_SASL" was never defined. Usually this means the macro was only invoked conditionally.
trying to autogen with ./autogen.sh --prefix=/usr --without-depends --without-sasl
I don't understand the problem, it seems AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) is set outside of any conditional block in configure.in
Right. Here's an untested patch: * configure.in (HAVE_SASL): Define unconditionally. Signed-off-by: Jim Meyering <meyering@redhat.com> --- configure.in | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/configure.in b/configure.in index 44bf59b..1876d81 100644 --- a/configure.in +++ b/configure.in @@ -377,6 +377,7 @@ LDFLAGS="$old_ldflags" dnl Cyrus SASL +have_sasl=0 AC_ARG_WITH(sasl, [ --with-sasl use cyrus SASL for authentication], [], @@ -402,8 +403,10 @@ if test "$with_sasl" != "no"; then CFLAGS="$old_cflags" LIBS="$old_libs" SASL_LIBS="$SASL_LIBS -lsasl2" - AC_DEFINE_UNQUOTED(HAVE_SASL, 1, [whether Cyrus SASL is available for authentication]) + have_sasl=1 fi +AC_DEFINE_UNQUOTED(HAVE_SASL, $have_sasl, + [whether Cyrus SASL is available for authentication]) AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) AC_SUBST(SASL_CFLAGS) AC_SUBST(SASL_LIBS) -- 1.5.4.rc4.15.g80bce
On Tue, Jan 22, 2008 at 02:38:27PM +0100, Jim Meyering wrote:
Daniel Veillard <veillard@redhat.com> wrote:
On Tue, Jan 22, 2008 at 08:00:34AM -0500, Daniel Veillard wrote:
On Mon, Jan 21, 2008 at 11:39:35PM +0000, Daniel P. Berrange wrote:
I would point you at the snapshot tar.gz here, but it appears to be not updated since September
./configure: line 35987: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35987: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
libvirt.org is a RHEL4 box, seems the pkgconfig requirements which were introduced break running autogen.sh , so no Makefile, make dist, and no snapshot apparently. I will try to investigate but I can't believe we managed to break detection for something as common as libxml2 *on xmlsoft.org itself*, the irony ...
Upgrading pkg-config on the box this goes further but then gets stuck at:
configure: error: conditional "HAVE_SASL" was never defined. Usually this means the macro was only invoked conditionally.
trying to autogen with ./autogen.sh --prefix=/usr --without-depends --without-sasl
I don't understand the problem, it seems AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) is set outside of any conditional block in configure.in
Right. Here's an untested patch: [...] dnl Cyrus SASL +have_sasl=0 AC_ARG_WITH(sasl, [ --with-sasl use cyrus SASL for authentication], [], @@ -402,8 +403,10 @@ if test "$with_sasl" != "no"; then CFLAGS="$old_cflags" LIBS="$old_libs" SASL_LIBS="$SASL_LIBS -lsasl2" - AC_DEFINE_UNQUOTED(HAVE_SASL, 1, [whether Cyrus SASL is available for authentication]) + have_sasl=1 fi +AC_DEFINE_UNQUOTED(HAVE_SASL, $have_sasl, + [whether Cyrus SASL is available for authentication]) AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) AC_SUBST(SASL_CFLAGS) AC_SUBST(SASL_LIBS)
Thanks Jim, looking at the patch I think I understand the error message now, but I applied the patch (or rather made the change manually), and I still get the same: ----- xmlsoft:~/libvirt -> ./autogen.sh --prefix=/usr --without-depends --without-sasl [no error reported until ...] checking whether NLS is requested... yes checking for GNU gettext in libc... yes checking whether to use NLS... yes checking where the gettext function comes from... libc configure: error: conditional "HAVE_SASL" was never defined. Usually this means the macro was only invoked conditionally. xmlsoft:~/libvirt -> ----- also I'm not sure, shouldn't the AM_CONDITIONAL test check $have_sasl instead or $with_sasl ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, Jan 22, 2008 at 09:10:07AM -0500, Daniel Veillard wrote:
On Tue, Jan 22, 2008 at 02:38:27PM +0100, Jim Meyering wrote:
Daniel Veillard <veillard@redhat.com> wrote:
Upgrading pkg-config on the box this goes further but then gets stuck at:
configure: error: conditional "HAVE_SASL" was never defined. Usually this means the macro was only invoked conditionally.
trying to autogen with ./autogen.sh --prefix=/usr --without-depends --without-sasl
I don't understand the problem, it seems AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) is set outside of any conditional block in configure.in
Right. Here's an untested patch: [...] dnl Cyrus SASL +have_sasl=0 AC_ARG_WITH(sasl, [ --with-sasl use cyrus SASL for authentication], [], @@ -402,8 +403,10 @@ if test "$with_sasl" != "no"; then CFLAGS="$old_cflags" LIBS="$old_libs" SASL_LIBS="$SASL_LIBS -lsasl2" - AC_DEFINE_UNQUOTED(HAVE_SASL, 1, [whether Cyrus SASL is available for authentication]) + have_sasl=1 fi +AC_DEFINE_UNQUOTED(HAVE_SASL, $have_sasl, + [whether Cyrus SASL is available for authentication]) AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) AC_SUBST(SASL_CFLAGS) AC_SUBST(SASL_LIBS)
Thanks Jim, looking at the patch I think I understand the error message now, but I applied the patch (or rather made the change manually), and I still get the same:
This is all because of the 'with_depends' stuff. If you have --without-depends then practically all of the configure.in script checks are within a giant conditional. This is redundant now we have the per-driver --with/with-{xen,qemu,test,...} flags, so I'm doing a patch to remove the with_depends flag. Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
"Daniel P. Berrange" <berrange@redhat.com> wrote: ...
This is all because of the 'with_depends' stuff. If you have --without-depends then practically all of the configure.in script checks are within a giant conditional.
This is redundant now we have the per-driver --with/with-{xen,qemu,test,...} flags, so I'm doing a patch to remove the with_depends flag.
Hah! You beat me to it. I had just reached the same conclusion.
Daniel Veillard <veillard@redhat.com> wrote:
On Tue, Jan 22, 2008 at 02:38:27PM +0100, Jim Meyering wrote:
Daniel Veillard <veillard@redhat.com> wrote:
On Tue, Jan 22, 2008 at 08:00:34AM -0500, Daniel Veillard wrote:
On Mon, Jan 21, 2008 at 11:39:35PM +0000, Daniel P. Berrange wrote:
I would point you at the snapshot tar.gz here, but it appears to be not updated since September
./configure: line 35987: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35987: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
libvirt.org is a RHEL4 box, seems the pkgconfig requirements which were introduced break running autogen.sh , so no Makefile, make dist, and no snapshot apparently. I will try to investigate but I can't believe we managed to break detection for something as common as libxml2 *on xmlsoft.org itself*, the irony ...
Upgrading pkg-config on the box this goes further but then gets stuck at:
configure: error: conditional "HAVE_SASL" was never defined. Usually this means the macro was only invoked conditionally.
trying to autogen with ./autogen.sh --prefix=/usr --without-depends --without-sasl
I don't understand the problem, it seems AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) is set outside of any conditional block in configure.in
Right. Here's an untested patch: [...] dnl Cyrus SASL +have_sasl=0 AC_ARG_WITH(sasl, [ --with-sasl use cyrus SASL for authentication], [], @@ -402,8 +403,10 @@ if test "$with_sasl" != "no"; then CFLAGS="$old_cflags" LIBS="$old_libs" SASL_LIBS="$SASL_LIBS -lsasl2" - AC_DEFINE_UNQUOTED(HAVE_SASL, 1, [whether Cyrus SASL is available for authentication]) + have_sasl=1 fi +AC_DEFINE_UNQUOTED(HAVE_SASL, $have_sasl, + [whether Cyrus SASL is available for authentication]) AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) AC_SUBST(SASL_CFLAGS) AC_SUBST(SASL_LIBS)
Thanks Jim, looking at the patch I think I understand the error message now, but I applied the patch (or rather made the change manually), and I still get the same: ----- xmlsoft:~/libvirt -> ./autogen.sh --prefix=/usr --without-depends --without-sasl
But if you omit the --without-depends (or remove the with-depends stuff altogether), my patch is still required to solve the problem. So I'll go ahead and check in the above patch as-is. It sounds like Dan's working on the independent remove-with-depends patch.
On Tue, Jan 22, 2008 at 04:44:39PM +0100, Jim Meyering wrote:
Daniel Veillard <veillard@redhat.com> wrote:
On Tue, Jan 22, 2008 at 02:38:27PM +0100, Jim Meyering wrote:
Daniel Veillard <veillard@redhat.com> wrote:
On Tue, Jan 22, 2008 at 08:00:34AM -0500, Daniel Veillard wrote:
On Mon, Jan 21, 2008 at 11:39:35PM +0000, Daniel P. Berrange wrote:
I would point you at the snapshot tar.gz here, but it appears to be not updated since September
./configure: line 35987: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35987: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
libvirt.org is a RHEL4 box, seems the pkgconfig requirements which were introduced break running autogen.sh , so no Makefile, make dist, and no snapshot apparently. I will try to investigate but I can't believe we managed to break detection for something as common as libxml2 *on xmlsoft.org itself*, the irony ...
Upgrading pkg-config on the box this goes further but then gets stuck at:
configure: error: conditional "HAVE_SASL" was never defined. Usually this means the macro was only invoked conditionally.
trying to autogen with ./autogen.sh --prefix=/usr --without-depends --without-sasl
I don't understand the problem, it seems AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) is set outside of any conditional block in configure.in
Right. Here's an untested patch: [...] dnl Cyrus SASL +have_sasl=0 AC_ARG_WITH(sasl, [ --with-sasl use cyrus SASL for authentication], [], @@ -402,8 +403,10 @@ if test "$with_sasl" != "no"; then CFLAGS="$old_cflags" LIBS="$old_libs" SASL_LIBS="$SASL_LIBS -lsasl2" - AC_DEFINE_UNQUOTED(HAVE_SASL, 1, [whether Cyrus SASL is available for authentication]) + have_sasl=1 fi +AC_DEFINE_UNQUOTED(HAVE_SASL, $have_sasl, + [whether Cyrus SASL is available for authentication]) AM_CONDITIONAL(HAVE_SASL, [test "$with_sasl" != "no"]) AC_SUBST(SASL_CFLAGS) AC_SUBST(SASL_LIBS)
Thanks Jim, looking at the patch I think I understand the error message now, but I applied the patch (or rather made the change manually), and I still get the same: ----- xmlsoft:~/libvirt -> ./autogen.sh --prefix=/usr --without-depends --without-sasl
But if you omit the --without-depends (or remove the with-depends stuff altogether), my patch is still required to solve the problem.
No it isn't - it works fine without it when i fix the other bits.
So I'll go ahead and check in the above patch as-is. It sounds like Dan's working on the independent remove-with-depends patch.
Please don't - it'll conflict with the changes I'm making Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
"Daniel P. Berrange" <berrange@redhat.com> wrote:
But if you omit the --without-depends (or remove the with-depends stuff altogether), my patch is still required to solve the problem.
No it isn't - it works fine without it when i fix the other bits.
Oh, I see, now. The conditionally AC_DEFINE'd HAVE_SASL has no bearing on the following AM_CONDITIONAL(HAVE_SASL,...
On Mon, Jan 21, 2008 at 05:27:33PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ah, I knew hyper was 64-bit, but it has no definition on OS X. I thought that long on OS X 10.5.1 was 64 bits in width -- my mistake.
XDR is a language for defining portable binary data formats. In the impl of XDR, a 'long' is encoded as a 32-bit integrate, regardless of what the C 'long' data type is. Furthermore, 'long' is actually deprecated because its pointless having 'long' and 'int' being the same. I'd still like to know what the compile failure you get is. If Mac OS is merely missing the definition of the 'xdr_hyper' function, it is quite possibly we could write a compatability function to make it work correctly. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is all the mentions of xdr_hyper in /usr/include on my box: [0]akutz@amends:libvirt-HEAD-20080121$ grep -R xdr_hyper /usr/include /usr/include/nfs/nfsm_subs.h: txdr_hyper(&__tmp64, (NMC)->nmc_ptr); \ /usr/include/nfs/nfsm_subs.h: fxdr_hyper(__tmpptr, &(LVAL)); \ /usr/include/nfs/xdr_subs.h:#define fxdr_hyper(f, t) { \ /usr/include/nfs/xdr_subs.h:#define txdr_hyper(f, t) { \ /usr/include/rpc/xdr.h:extern bool_t xdr_hyper(XDR *, quad_t *); I tried including xdr.h in the remote_control.x file but that did not work. I am not familiar with the XDR language, so please pardon my ignorance. Thank you again for your help. - -- - -a On Jan 21, 2008, at 5:46 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 05:27:33PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ah, I knew hyper was 64-bit, but it has no definition on OS X. I thought that long on OS X 10.5.1 was 64 bits in width -- my mistake.
XDR is a language for defining portable binary data formats. In the impl of XDR, a 'long' is encoded as a 32-bit integrate, regardless of what the C 'long' data type is. Furthermore, 'long' is actually deprecated because its pointless having 'long' and 'int' being the same.
I'd still like to know what the compile failure you get is. If Mac OS is merely missing the definition of the 'xdr_hyper' function, it is quite possibly we could write a compatability function to make it work correctly.
Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlS9qTg8lceyAqqQRAhtLAJ9GLXBv0dZBr03I0S5vbOCMSILZKQCg4y+K RquebScbWTVpahKIlYmye38= =3dvP -----END PGP SIGNATURE-----
I've attached the compile failure I get. -- -a On Jan 21, 2008, at 5:46 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 05:27:33PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ah, I knew hyper was 64-bit, but it has no definition on OS X. I thought that long on OS X 10.5.1 was 64 bits in width -- my mistake.
XDR is a language for defining portable binary data formats. In the impl of XDR, a 'long' is encoded as a 32-bit integrate, regardless of what the C 'long' data type is. Furthermore, 'long' is actually deprecated because its pointless having 'long' and 'int' being the same.
I'd still like to know what the compile failure you get is. If Mac OS is merely missing the definition of the 'xdr_hyper' function, it is quite possibly we could write a compatability function to make it work correctly.
Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Mon, Jan 21, 2008 at 05:52:06PM -0600, Schley Andrew Kutz wrote:
I've attached the compile failure I get.
Ok, so your header files suggest Mac OS *does* have xdr_hyper, and this failure is a link time failure: Undefined symbols: "_xdr_quad_t", referenced from: _xdr_remote_sched_param_value in libvirtd-remote_protocol.o _xdr_remote_get_version_ret in libvirtd-remote_protocol.o _xdr_remote_domain_block_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_block_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_block_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_block_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_block_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_interface_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_interface_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_interface_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_interface_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_interface_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_interface_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_interface_stats_ret in libvirtd-remote_protocol.o _xdr_remote_domain_interface_stats_ret in libvirtd-remote_protocol.o _xdr_remote_node_get_info_ret in libvirtd-remote_protocol.o _xdr_remote_node_get_info_ret in libvirtd-remote_protocol.o _xdr_remote_node_get_info_ret in libvirtd-remote_protocol.o So my guess is that we're missing a library at link time. I'm not sure if it will help, but you could try something like... make LDFLAGS="-lxdr" or make LDFLAGS="-lrpc" Or make LDFLAGS="-lrpc -lxdr" Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Tue, Jan 22, 2008 at 12:01:10AM +0000, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 05:52:06PM -0600, Schley Andrew Kutz wrote:
I've attached the compile failure I get.
Ok, so your header files suggest Mac OS *does* have xdr_hyper, and this failure is a link time failure:
Undefined symbols: "_xdr_quad_t", referenced from:
Actually scratch my other idea. I think that this is a problem with the code we generated on Linux not being portable. ie, GLibC's rpcgen program generated a remote_protocol.c file which contains a glibc specific call to xdr_quad_t which Mac OS X does not have. We need to re-generate the code on Mac OS, so try the following... # cd qemud # rm remote_protocol.c # make remote_protocol.c # cd .. # make clean This should have created a new 'remote_protocol.c' using Apple's rpcgen program. So now try and build the whole of libvirt again. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [0]akutz@amends:qemud$ make remote_protocol.c rm -f remote_protocol.c rpcgen -c -o remote_protocol.c remote_protocol.x unsigned hyper cpu_time; ^^^^^^^^^^^^^^^^^^^^^^^^^^^ remote_protocol.x, line 144: expected ';' make: *** [remote_protocol.c] Error 1 - -- - -a On Jan 21, 2008, at 6:10 PM, Daniel P. Berrange wrote:
make remote_protocol.c
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlTZSTg8lceyAqqQRAnAfAKDtl9hWgAWM8RfpmYgwNb9iEqGLOQCg1gll 4l06YIrK3+die3EUkU7ukD8= =/47m -----END PGP SIGNATURE-----
On Mon, Jan 21, 2008 at 06:18:26PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[0]akutz@amends:qemud$ make remote_protocol.c rm -f remote_protocol.c rpcgen -c -o remote_protocol.c remote_protocol.x unsigned hyper cpu_time; ^^^^^^^^^^^^^^^^^^^^^^^^^^^ remote_protocol.x, line 144: expected ';' make: *** [remote_protocol.c] Error 1
Could you try changing 'cpu_time' to 'cpuTime' - it may not like the underscore. If it doesn't we'll have quite alot to fix up :-) Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Not it. When I changed all instances of hyper to long earlier it worked. The hyper is not getting parses. That said, I'll still try your suggestion when I'm back in front of my keyboard. -- -a On Jan 21, 2008, at 6:32 PM, "Daniel P. Berrange" <berrange@redhat.com> wrote:
On Mon, Jan 21, 2008 at 06:18:26PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[0]akutz@amends:qemud$ make remote_protocol.c rm -f remote_protocol.c rpcgen -c -o remote_protocol.c remote_protocol.x unsigned hyper cpu_time; ^^^^^^^^^^^^^^^^^^^^^^^^^^^ remote_protocol.x, line 144: expected ';' make: *** [remote_protocol.c] Error 1
Could you try changing 'cpu_time' to 'cpuTime' - it may not like the underscore. If it doesn't we'll have quite alot to fix up :-)
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Verified that camelCase does not help. - -- - -a On Jan 21, 2008, at 6:46 PM, Schley Andrew Kutz wrote:
Not it. When I changed all instances of hyper to long earlier it worked. The hyper is not getting parses. That said, I'll still try your suggestion when I'm back in front of my keyboard.
-- -a
On Jan 21, 2008, at 6:32 PM, "Daniel P. Berrange" <berrange@redhat.com> wrote:
On Mon, Jan 21, 2008 at 06:18:26PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[0]akutz@amends:qemud$ make remote_protocol.c rm -f remote_protocol.c rpcgen -c -o remote_protocol.c remote_protocol.x unsigned hyper cpu_time; ^^^^^^^^^^^^^^^^^^^^^^^^^^^ remote_protocol.x, line 144: expected ';' make: *** [remote_protocol.c] Error 1
Could you try changing 'cpu_time' to 'cpuTime' - it may not like the underscore. If it doesn't we'll have quite alot to fix up :-)
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlUKKTg8lceyAqqQRAnBPAJ0V2qX3Y0CyaF1xSUCMziWCMFSYmwCgvcui bQQXVnHaeQO+jBxa35YH1xs= =V4VZ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Okay, I am following up on this: http://sourceware.org/ml/libc-alpha/2001-04/msg00012.html - -- - -a On Jan 21, 2008, at 6:32 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 06:18:26PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[0]akutz@amends:qemud$ make remote_protocol.c rm -f remote_protocol.c rpcgen -c -o remote_protocol.c remote_protocol.x unsigned hyper cpu_time; ^^^^^^^^^^^^^^^^^^^^^^^^^^^ remote_protocol.x, line 144: expected ';' make: *** [remote_protocol.c] Error 1
Could you try changing 'cpu_time' to 'cpuTime' - it may not like the underscore. If it doesn't we'll have quite alot to fix up :-)
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlUX7Tg8lceyAqqQRAqBXAKCc/I3CFAin7yHcldQLXENR3skvFQCg3JaJ 8StwArTCCRI/uoRSuZPPv4s= =ZK7L -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nevermind, I missed the date. Although, I do wonder if rpcgen on OS X supports 'hyper'? I am doing some digging to find out if it does. - -- - -a On Jan 21, 2008, at 7:25 PM, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Okay, I am following up on this: http://sourceware.org/ml/libc-alpha/2001-04/msg00012.html
- -- - -a
On Jan 21, 2008, at 6:32 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 06:18:26PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[0]akutz@amends:qemud$ make remote_protocol.c rm -f remote_protocol.c rpcgen -c -o remote_protocol.c remote_protocol.x unsigned hyper cpu_time; ^^^^^^^^^^^^^^^^^^^^^^^^^^^ remote_protocol.x, line 144: expected ';' make: *** [remote_protocol.c] Error 1
Could you try changing 'cpu_time' to 'cpuTime' - it may not like the underscore. If it doesn't we'll have quite alot to fix up :-)
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHlUX7Tg8lceyAqqQRAqBXAKCc/I3CFAin7yHcldQLXENR3skvFQCg3JaJ 8StwArTCCRI/uoRSuZPPv4s= =ZK7L -----END PGP SIGNATURE-----
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlUaeTg8lceyAqqQRAo4cAKDSvIA5gz4hLIMCVpjAhqmV1kFvxwCeLDPm pD6JXBUPcmrBW9bAxADGjII= =bJjN -----END PGP SIGNATURE-----
On Mon, Jan 21, 2008 at 07:27:58PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nevermind, I missed the date. Although, I do wonder if rpcgen on OS X supports 'hyper'? I am doing some digging to find out if it does.
The Apple docs definitely suggest their XDR library suports it, so there must be a way to get their rpcgen tool to suport it http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/xdr.... One other idea is to try changing 'hyper' to 'quad' or 'quad_t' or 'long long' or 'int64_t'. These are all alternative ways of naming a 64-bit integer. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Unfortunately none of your suggestions work, and I also found this http://svn.pdos.csail.mit.edu/svn/uia/trunk/uia/?view=log&pathrev=885 (search for hyper) which suggests only 21 months ago that OS X does not support hyper. However, this does not preclude Leopard supporting it, although emperical evidence would suggest that support is still lacking. - -- - -a On Jan 21, 2008, at 7:39 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 07:27:58PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nevermind, I missed the date. Although, I do wonder if rpcgen on OS X supports 'hyper'? I am doing some digging to find out if it does.
The Apple docs definitely suggest their XDR library suports it, so there must be a way to get their rpcgen tool to suport it
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/xdr....
One other idea is to try changing 'hyper' to 'quad' or 'quad_t' or 'long long' or 'int64_t'. These are all alternative ways of naming a 64-bit integer.
Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlVVETg8lceyAqqQRAufQAJ97n0oQ1y+Sg3+NyDn4f3g+pYiVNgCbBJWs XfS3c85twJ9x3upU+crCiY8= =8BXd -----END PGP SIGNATURE-----
On Mon, Jan 21, 2008 at 08:30:28PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Unfortunately none of your suggestions work, and I also found this http://svn.pdos.csail.mit.edu/svn/uia/trunk/uia/?view=log&pathrev=885 (search for hyper) which suggests only 21 months ago that OS X does not support hyper. However, this does not preclude Leopard supporting it, although emperical evidence would suggest that support is still lacking.
Ok, so if they really don't support hyper, then I've two final ideas, the first of which will definitely work, but requires some coding on our part. we define a new type typedef remote_int64 int[2]; typedef remote_uint64 unsigned int[2]; and then replace all use of hyper/unsigned hyper with remote_int64 and remote_uint64. And define our own code to marshall this on/off the wire. We'd merely have to take care to get the 2 bytes in the correct order to match the current definition of hyper. Other option is to not re-run rpcgen on Mac, and simply try and define an impl for that missing _xdr_quad_t function symbol so it links. The latter might be simpler, but is a slightly evil hack.. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'll try the latter. However, from an earlier e-mail I pointed out that I cannot get the 'make dist' to work on Linux. It moans about a missing help file: cp: cannot stat `./libvirt.devhelp': No such file or directory make[2]: *** [distdir] Error 1 make[2]: Leaving directory `/usr/local/src/libvirt/docs/devhelp' make[1]: *** [distdir] Error 1 make[1]: Leaving directory `/usr/local/src/libvirt/docs' make: *** [distdir] Error 1 Ideas? - -- - -a On Jan 21, 2008, at 10:32 PM, Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 08:30:28PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Unfortunately none of your suggestions work, and I also found this http://svn.pdos.csail.mit.edu/svn/uia/trunk/uia/?view=log&pathrev=885 (search for hyper) which suggests only 21 months ago that OS X does not support hyper. However, this does not preclude Leopard supporting it, although emperical evidence would suggest that support is still lacking.
Ok, so if they really don't support hyper, then I've two final ideas, the first of which will definitely work, but requires some coding on our part. we define a new type
typedef remote_int64 int[2]; typedef remote_uint64 unsigned int[2];
and then replace all use of hyper/unsigned hyper with remote_int64 and remote_uint64. And define our own code to marshall this on/off the wire. We'd merely have to take care to get the 2 bytes in the correct order to match the current definition of hyper.
Other option is to not re-run rpcgen on Mac, and simply try and define an impl for that missing _xdr_quad_t function symbol so it links.
The latter might be simpler, but is a slightly evil hack..
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlXNoTg8lceyAqqQRAmlnAKCGOHqE+vXBfM/1FZ38awwWED/7jgCfXW1w SDXWZbhRwUg3m9A8EZqXatM= =WM+W -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not so much. I added the two headers from http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/xdr.... to remote_protocol.x and the gen fails: [0]akutz@amends:libvirt-0.4.0$ make -C qemud remote_protocol.c rm -f remote_protocol.h rpcgen -h -o remote_protocol.h remote_protocol.x unsigned hyper cpu_time; ^^^^^^^^^^^^^^^^^^^^^^^^^^^ remote_protocol.x, line 146: expected ';' make: *** [remote_protocol.h] Error 1 I also tried adding them directly to the remote_protocol.c and .h and then the major make fails in the way I already showed you. Ideas? - -- - -a On Jan 21, 2008, at 6:01 PM, Daniel P. Berrange wrote:
LDFLAGS="-lxdr"
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlTVQTg8lceyAqqQRApgaAJ9n2PLsk0N2+3ZHaZKrmcV3bSJ7QgCgvZoI ni0O0jNFxbW1BoG/7uysW9w= =rvLD -----END PGP SIGNATURE-----
Daniel P. Berrange wrote:
On Mon, Jan 21, 2008 at 04:50:29PM -0600, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I spent the weekend attempting to get libvirt working on OS X Leopard 10.5.1. I was able to get it to compile, but not connect to libvirtd running on either my KVM or Xen servers. Here are the instructions for getting it to compile:
1. Download libvirt-0.4.0 from the mirrors.
2. Use macports to install pkgconfig and gnutls
3. Configure your source:
./configure --without-xen --without-qemu
4. Replace instances of 'hyper' in qemu/remote_protocol.x with 'long' and then follow the instructions on http://libvirt.org/windows.html to regen XDR structures.
This is going to fail big time. 'hyper' is 64-bit in size, where as long is 32-bit. Any RPC calls which user hyper will crash and burn if you make this change.
What errors do you get if you don't make this change ? There may be better ways to provide compatability.
This was essentially the problem that I hit when trying to port to Leopard also over the weekend. There is no hyper/64 bit support in the Mac-supplied rpcgen program. There are two alternatives I can think of: Probably the simplest is to compile the RPC bindings which are generated on Linux and supplied with libvirt in CVS and the tarball (ie. remote_protocol.[ch]). We need to supply only the xdr_quad type and a handful of 64 bit functions. I did the same thing for Windows but in that case built my own version of a mini-XDR library with some contributions from glibc. What we could do is bundle this mini-XDR library with libvirt itself (or perhaps persuade gnulib to take it -- Jim?). Another, less appealing, is to look at some of the modern XDR library replacements. Uli suggested one, but I've lost the link at the moment... Of course that involves porting those libraries to Mac and Windows, which may be a load of effort in itself. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
"Richard W.M. Jones" <rjones@redhat.com> wrote: ...
There are two alternatives I can think of:
Probably the simplest is to compile the RPC bindings which are generated on Linux and supplied with libvirt in CVS and the tarball (ie. remote_protocol.[ch]). We need to supply only the xdr_quad type
Hi Rich, I like the idea of distributing the generated files. Far less maintenance hassle that way. Of course, that means we're saying developers (or anyone running "make dist") have to use a sufficiently featureful system. I think that is the only sane way to go. It's the same philosophy that says you can turn up compiler-warning- detection to the maximum and expect no warnings only on a relatively modern and properly configured system. If having people run distrib-building tools on inadequate systems starts happening too often, we can add an autoconf test to detect the losing tool(s) and warn them about it.
and a handful of 64 bit functions. I did the same thing for Windows but in that case built my own version of a mini-XDR library with some contributions from glibc. What we could do is bundle this mini-XDR library with libvirt itself (or perhaps persuade gnulib to take it -- Jim?).
Doesn't hurt to ask, but once something like that is being used by two or more projects, it's even easier to justify. However, I confess I don't know enough about the alternatives you mention (below) to say if it's worth pursuing.
Another, less appealing, is to look at some of the modern XDR library replacements. Uli suggested one, but I've lost the link at the moment... Of course that involves porting those libraries to Mac and Windows, which may be a load of effort in itself.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim, I am posting this to the list because, well, of what I am posting. Mail to you is bouncing. - -- - -a On Jan 22, 2008, at 6:53 AM, Jim Meyering wrote:
"Richard W.M. Jones" <rjones@redhat.com> wrote: ...
There are two alternatives I can think of:
Probably the simplest is to compile the RPC bindings which are generated on Linux and supplied with libvirt in CVS and the tarball (ie. remote_protocol.[ch]). We need to supply only the xdr_quad type
Hi Rich,
I like the idea of distributing the generated files. Far less maintenance hassle that way. Of course, that means we're saying developers (or anyone running "make dist") have to use a sufficiently featureful system. I think that is the only sane way to go. It's the same philosophy that says you can turn up compiler-warning- detection to the maximum and expect no warnings only on a relatively modern and properly configured system.
If having people run distrib-building tools on inadequate systems starts happening too often, we can add an autoconf test to detect the losing tool(s) and warn them about it.
and a handful of 64 bit functions. I did the same thing for Windows but in that case built my own version of a mini-XDR library with some contributions from glibc. What we could do is bundle this mini-XDR library with libvirt itself (or perhaps persuade gnulib to take it -- Jim?).
Doesn't hurt to ask, but once something like that is being used by two or more projects, it's even easier to justify. However, I confess I don't know enough about the alternatives you mention (below) to say if it's worth pursuing.
Another, less appealing, is to look at some of the modern XDR library replacements. Uli suggested one, but I've lost the link at the moment... Of course that involves porting those libraries to Mac and Windows, which may be a load of effort in itself.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHleg5Tg8lceyAqqQRAteeAJ4zU7nI9Y5RuwNRYMA/LBuzirs73gCaA76j 9CgOEgbhqxcvj5ihIytL0Zs= =vjz7 -----END PGP SIGNATURE-----
Jim Meyering wrote:
However, I confess I don't know enough about the alternatives you mention (below) to say if it's worth pursuing.
Another, less appealing, is to look at some of the modern XDR library replacements. Uli suggested one, but I've lost the link at the moment... Of course that involves porting those libraries to Mac and Windows, which may be a load of effort in itself.
It's TI-RPC. Unfortunately the licensing of TI-RPC is very confused (see section 3.13 "Other SunRPC libraries, TI-RPC" of http://et.redhat.com/~rjones/secure_rpc/). In any case it would involve a bunch of extra porting work, so it's easier just to fix the missing xdr_quad_t type. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Mon, Jan 21, 2008 at 04:50:29PM -0600, Schley Andrew Kutz wrote:
5. Edit '/usr/include/net/if.h' and add the following include:
#include <net/if_var.h> #include <sys/types.h>
// // EDIT: akutz // #include <sys/socket.h>
This is curious - I'm puzzelled why libvirt source uses 'net/if.h' at all. This is for getting information about network interfaces and not something that libvirt should need to use AFAICT. Perhaps we should just remove 'net/if.h' from our code
6. Create a symlink for 'malloc.h' so the libvirt source can find it:
sudo ln -s /usr/include/malloc/malloc.h /usr/include/malloc.h
Again I'm puzzelled why libvirt includes malloc.h at all - the definition of malloc comes from stdlib.h. Historical accident probably.
7. Add a header to "src/remote_internal.c":
// // EDIT: akutz // #include <sys/un.h>
Yep, this is a clear bug in our remote_internal.c file.
8. The version-script parameter of ld is not portable to OS X. Edit 'src/Makefile':
# # EDIT: akutz # #libvirt_la_LDFLAGS = -Wl,--version-script=$(srcdir)/ libvirt_sym.version \ # -version-info 4:0:4 \ # $(COVERAGE_CFLAGS:-f%=-Wc,-f%) \
Ok, we should be able to fix the makefile to only use libvirt_sym.version when running on a suitable OS to avoid you needing to make this change. So I reckon all 4 of these issues are easily fixable in libvirt source... Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Attached is as far as I got over the weekend. As you can see the main problems (apart from the lack of hyper which is a showstopper) are: * Minor header tweaks * PKG_CHECK_EXISTS macro doesn't exist and has to be commented out everywhere. This is despite the fact that I have pkg-config from Macports installed. * --version-script not supported by the linker It's actually very close to working, and I think it will be considerably simpler to port and maintain a Mac OS X port than the wretched Windows port. The OCaml bindings & tools built first time on Mac OS X, but obviously I couldn't finish the final link since there wasn't a libvirt.dylib. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Richard W.M. Jones wrote:
* PKG_CHECK_EXISTS macro doesn't exist and has to be commented out everywhere. This is despite the fact that I have pkg-config from Macports installed.
Looking into this in a bit more detail -- Macports installs everything under /opt/local and there is a pkg.m4 file under there which contains PKG_CHECK_EXISTS macro: $ grep PKG_CHECK_EXISTS /opt/local/share/aclocal/pkg.m4 # PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) # PKG_CHECK_EXISTS manually AC_DEFUN([PKG_CHECK_EXISTS], PKG_CHECK_EXISTS([$3], What do I need to do to make autoconf use this macro? At the moment autoconf leaves the macro unexpanded, and as a result ./configure fails. checking for iptables... /sbin/iptables ./configure: line 35741: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35741: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)' Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I got it to build on my Mac (somewhat more correctly this time), but it still fails to connect to the daemon on the other side (see report below). How I did it: 1. Build on Linux 2. Run 'make dist' 3. Copy tarball over to Mac 4. Re-configure without xen and qemu 5. Make changes (with exception of the change to remote_protocol.x) I identified here, https://www.redhat.com/archives/libvir-list/2008-January/msg00319.html . 6. Add #include <rpc/xdr.h> to qemu/remote_protocol.h. This fixes the build problem where it cannot find the symbol _xdr_quad_t. 7. Build The build still partially fails because it attempts to regenerate remote_protocol.[ch] at the end, but the normal build does complete. However, it still throws a fatal exception when connecting to a remote server. Process: Python [3685] Path: /System/Library/Frameworks/Python.framework/Versions/ 2.5/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [59098] Date/Time: 2008-01-22 06:51:26.800 -0600 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004 Crashed Thread: 0 Thread 0 Crashed: 0 libvirt.0.dylib 0x00412911 remoteAuthenticate + 1345 1 libvirt.0.dylib 0x00414869 doRemoteOpen + 3593 2 libvirt.0.dylib 0x00415499 remoteOpen + 137 3 libvirt.0.dylib 0x00401438 do_open + 392 4 libvirtmod.so 0x000c0e06 libvirt_virConnectOpen + 102 5 org.python.python 0x0018d826 PyEval_EvalFrameEx + 17116 6 org.python.python 0x0018da08 PyEval_EvalFrameEx + 17598 7 org.python.python 0x0018f47b PyEval_EvalCodeEx + 1638 8 org.python.python 0x0018f568 PyEval_EvalCode + 87 9 org.python.python 0x001a6a0c PyErr_Display + 1896 10 org.python.python 0x001a7036 PyRun_FileExFlags + 135 11 org.python.python 0x001a89a2 PyRun_SimpleFileExFlags + 421 12 org.python.python 0x001b3c23 Py_Main + 3095 13 org.python.pythonapp 0x00001fca 0x1000 + 4042 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x004123e1 ecx: 0xbfffe806 edx: 0x00000000 edi: 0x00000000 esi: 0xbfffe90c ebp: 0xbfffea28 esp: 0xbfffe840 ss: 0x0000001f efl: 0x00010202 eip: 0x00412911 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x00000004 Binary Images: 0x1000 - 0x1ffe org.python.pythonapp 2.5.0 (2.5.0a0) <a2ccf04a940c23b34c33d7fe108d773e> /System/Library/Frameworks/ Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python 0x49000 - 0x4bfff +libgpg-error.0.dylib ??? (???) /opt/local/ lib/libgpg-error.0.dylib 0xbb000 - 0xc2ff3 +libvirtmod.so ??? (???) <20dea38de64927c9e8b50a1fa240e067> /usr/local/lib/python2.5/site- packages/libvirtmod.so 0x118000 - 0x1e3ffb org.python.python 2.5 (2.5) <9786e5d8790a594bb7b3cdcf9a9d0b49> /System/Library/Frameworks/ Python.framework/Versions/2.5/Python 0x2f0000 - 0x2f7ff3 +libintl.8.dylib ??? (???) /opt/local/lib/ libintl.8.dylib 0x400000 - 0x424fef +libvirt.0.dylib ??? (???) <70af9029fa4c7accc04377f0f65c53ae> /usr/local/lib/libvirt.0.dylib 0x43b000 - 0x49bfff +libgnutls.26.dylib ??? (???) /opt/local/lib/ libgnutls.26.dylib 0x4b5000 - 0x4c2fe2 +libtasn1.3.dylib ??? (???) /opt/local/lib/ libtasn1.3.dylib 0x4c7000 - 0x528ff3 +libgcrypt.11.dylib ??? (???) <76bad0ad90909bf99f422f8bbfd61124> /opt/local/lib/libgcrypt.11.dylib 0x540000 - 0x637ff0 +libiconv.2.dylib ??? (???) /opt/local/lib/ libiconv.2.dylib 0x644000 - 0x654ffd +libz.1.dylib ??? (???) /opt/local/lib/libz. 1.dylib 0x65f000 - 0x661ffc apop.so ??? (???) <8e5cbfa49bbed80ed34f03e008e3e086> /usr/lib/sasl2/apop.so 0x665000 - 0x67dfe2 dhx.so ??? (???) <0831cf2893deaa2b5525ea7bfda17404> /usr/lib/sasl2/dhx.so 0x68c000 - 0x694fff digestmd5WebDAV.so ??? (???) <42e13c06e037f02eee71a43324169f62> /usr/lib/sasl2/digestmd5WebDAV.so 0x698000 - 0x69afff libanonymous.2.so ??? (???) <161902c9ed78dce78b61125c7c155f0f> /usr/lib/sasl2/libanonymous.2.so 0x69e000 - 0x6a0ffc libcrammd5.2.so ??? (???) <c917c89eefddcfcacf48c939c3af12aa> /usr/lib/sasl2/libcrammd5.2.so 0x6a4000 - 0x6adffb libdigestmd5.2.so ??? (???) <c8595204acd0e7cb362b33d008693019> /usr/lib/sasl2/libdigestmd5.2.so 0x6b1000 - 0x6b5fff libgssapiv2.2.so ??? (???) <a47ee23249e7c36aee418a6e7fd3a502> /usr/lib/sasl2/libgssapiv2.2.so 0x6bb000 - 0x6bdffc login.so ??? (???) <03d28ec908a6ed9abee1b25fe87716ef> /usr/lib/sasl2/login.so 0x6c1000 - 0x6c8ffc libotp.2.so ??? (???) <0b7c8cd165835331c586e49465ef1186> /usr/lib/sasl2/libotp.2.so 0x6d2000 - 0x6d4ffc libplain.2.so ??? (???) <5992f1149ff6cc7fadafa2bfd4ecc00a> /usr/lib/sasl2/libplain.2.so 0x6d8000 - 0x6ddffc libpps.so ??? (???) <ae02d7b23951bddb4db705b2d632c6ac> /usr/lib/sasl2/libpps.so 0x6e3000 - 0x6e6fff mschapv2.so ??? (???) <8d5951f3d3a0565fd772ebec4d2054fb> /usr/lib/sasl2/mschapv2.so 0x6ea000 - 0x6ecffc shadow_auxprop.so ??? (???) <5137115453406a92cf514b65046a6b28> /usr/lib/sasl2/shadow_auxprop.so 0x6f2000 - 0x6f4ffd smb_lm.so ??? (???) <e9ad275441e15388bf580b1cdf55b430> /usr/lib/sasl2/smb_lm.so 0x6f8000 - 0x6faffc smb_nt.so ??? (???) <a7144a88919b4aea313caf6c4e86353a> /usr/lib/sasl2/smb_nt.so 0x6fe000 - 0x701ff0 smb_ntlmv2.so ??? (???) <ccfa6d0eafa992db95ad309e32c6d400> /usr/lib/sasl2/smb_ntlmv2.so 0x8fe00000 - 0x8fe2d883 dyld 95.3 (???) <81592e798780564b5d46b988f7ee1a6a> /usr/lib/dyld 0x90d29000 - 0x90e5bfe7 com.apple.CoreFoundation 6.5 (476) <8bfebc0dbad6fc33bea0fa00a1b9ec37> /System/Library/Frameworks/ CoreFoundation.framework/Versions/A/CoreFoundation 0x90e5c000 - 0x90e7aff3 com.apple.DirectoryService.Framework 3.5 (3.5) <899d8c9ee31b004a6ff73dab88982b1a> /System/Library/Frameworks/ DirectoryService.framework/Versions/A/DirectoryService 0x922a3000 - 0x92353fff edu.mit.Kerberos 6.0.11 (6.0.11) <33c25789baedcd70a7e24881775dd9ad> /System/Library/Frameworks/ Kerberos.framework/Versions/A/Kerberos 0x9244f000 - 0x924acffb libstdc++.6.dylib ??? (???) <04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib 0x92510000 - 0x926d9fef com.apple.security 5.0.1 (32736) <8c9eda0fcc1d8a571543025ac900715f> /System/Library/Frameworks/ Security.framework/Versions/A/Security 0x92f62000 - 0x92f80fff libresolv.9.dylib ??? (???) <54e6a08c2f108bdf5916fb483d51961b> /usr/lib/libresolv.9.dylib 0x93661000 - 0x9366fffd libz.1.dylib ??? (???) <5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib 0x936a2000 - 0x93783ff7 libxml2.2.dylib ??? (???) <450ec38b57fb46013847cce851001a2f> /usr/lib/libxml2.2.dylib 0x93d28000 - 0x93d2ffe9 libgcc_s.1.dylib ??? (???) <f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib 0x94a5b000 - 0x94b93ff7 libicucore.A.dylib ??? (???) <afcea652ff2ec36885b2c81c57d06d4c> /usr/lib/libicucore.A.dylib 0x95a7f000 - 0x95b5efff libobjc.A.dylib ??? (???) <5eda47fec2d0e7853b3506aa1fd2dafa> /usr/lib/libobjc.A.dylib 0x9631e000 - 0x963d0ffb libcrypto.0.9.7.dylib ??? (???) <330b0e48e67faffc8c22dfc069ca7a47> /usr/lib/libcrypto.0.9.7.dylib 0x9642c000 - 0x9643bfff libsasl2.2.dylib ??? (???) <b9e1ca0b6612e280b6cbea6df0eec5f6> /usr/lib/libsasl2.2.dylib 0x9643c000 - 0x96466fef libauto.dylib ??? (???) <d468bc4a8a69343f1748c293db1b57fb> /usr/lib/libauto.dylib 0x96d8c000 - 0x96d8dfef libmathCommon.A.dylib ??? (???) /usr/lib/ system/libmathCommon.A.dylib 0x96d9a000 - 0x96ef4fe3 libSystem.B.dylib ??? (???) <8ecc83dc0399be3946f7a46e88cf4bbb> /usr/lib/libSystem.B.dylib 0xfffe8000 - 0xfffebfff libobjc.A.dylib ??? (???) /usr/lib/ libobjc.A.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/ libSystem.B.dylib - -- - -a On Jan 22, 2008, at 6:41 AM, Richard W.M. Jones wrote:
Richard W.M. Jones wrote:
* PKG_CHECK_EXISTS macro doesn't exist and has to be commented out everywhere. This is despite the fact that I have pkg-config from Macports installed.
Looking into this in a bit more detail -- Macports installs everything under /opt/local and there is a pkg.m4 file under there which contains PKG_CHECK_EXISTS macro:
$ grep PKG_CHECK_EXISTS /opt/local/share/aclocal/pkg.m4 # PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) # PKG_CHECK_EXISTS manually AC_DEFUN([PKG_CHECK_EXISTS], PKG_CHECK_EXISTS([$3],
What do I need to do to make autoconf use this macro? At the moment autoconf leaves the macro unexpanded, and as a result ./configure fails.
checking for iptables... /sbin/iptables ./configure: line 35741: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35741: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
Rich.
-- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlef9Tg8lceyAqqQRAmf7AJ4ikQJW/JjuWABbym07GuUWqdSe6gCgmpyD znJiL5O+1FBs6yd8NMFpqsY= =OutF -----END PGP SIGNATURE-----
Schley Andrew Kutz wrote:
6. Add #include <rpc/xdr.h> to qemu/remote_protocol.h. This fixes the build problem where it cannot find the symbol _xdr_quad_t.
Adding this header doesn't help me to get xdr_quad_t ... that just doesn't exist in the Leopard header files. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It makes the 'missing symbol' warnings go away. - -- - -a On Jan 22, 2008, at 9:15 AM, Richard W.M. Jones wrote:
Schley Andrew Kutz wrote:
6. Add #include <rpc/xdr.h> to qemu/remote_protocol.h. This fixes the build problem where it cannot find the symbol _xdr_quad_t.
Adding this header doesn't help me to get xdr_quad_t ... that just doesn't exist in the Leopard header files.
Rich.
-- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlgnxTg8lceyAqqQRArtsAJ9470heaup+RWHXGYacO450XxAu7ACgsdqB 9DcM7QKHmiZ5cP5JYbYh0+4= =9r7W -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to figure out why the exception is getting thrown. I built it from HEAD, and I still cannot connect. Do we still think this ties back to the XDR problems? - -- - -a On Jan 22, 2008, at 6:56 AM, Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I got it to build on my Mac (somewhat more correctly this time), but it still fails to connect to the daemon on the other side (see report below). How I did it:
1. Build on Linux 2. Run 'make dist' 3. Copy tarball over to Mac 4. Re-configure without xen and qemu 5. Make changes (with exception of the change to remote_protocol.x) I identified here, https://www.redhat.com/archives/libvir-list/2008-January/msg00319.html . 6. Add #include <rpc/xdr.h> to qemu/remote_protocol.h. This fixes the build problem where it cannot find the symbol _xdr_quad_t. 7. Build
The build still partially fails because it attempts to regenerate remote_protocol.[ch] at the end, but the normal build does complete. However, it still throws a fatal exception when connecting to a remote server.
Process: Python [3685] Path: /System/Library/Frameworks/Python.framework/ Versions/2.5/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [59098]
Date/Time: 2008-01-22 06:51:26.800 -0600 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004 Crashed Thread: 0
Thread 0 Crashed: 0 libvirt.0.dylib 0x00412911 remoteAuthenticate + 1345 1 libvirt.0.dylib 0x00414869 doRemoteOpen + 3593 2 libvirt.0.dylib 0x00415499 remoteOpen + 137 3 libvirt.0.dylib 0x00401438 do_open + 392 4 libvirtmod.so 0x000c0e06 libvirt_virConnectOpen + 102 5 org.python.python 0x0018d826 PyEval_EvalFrameEx + 17116 6 org.python.python 0x0018da08 PyEval_EvalFrameEx + 17598 7 org.python.python 0x0018f47b PyEval_EvalCodeEx + 1638 8 org.python.python 0x0018f568 PyEval_EvalCode + 87 9 org.python.python 0x001a6a0c PyErr_Display + 1896 10 org.python.python 0x001a7036 PyRun_FileExFlags + 135 11 org.python.python 0x001a89a2 PyRun_SimpleFileExFlags + 421 12 org.python.python 0x001b3c23 Py_Main + 3095 13 org.python.pythonapp 0x00001fca 0x1000 + 4042
Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x004123e1 ecx: 0xbfffe806 edx: 0x00000000 edi: 0x00000000 esi: 0xbfffe90c ebp: 0xbfffea28 esp: 0xbfffe840 ss: 0x0000001f efl: 0x00010202 eip: 0x00412911 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x00000004
Binary Images: 0x1000 - 0x1ffe org.python.pythonapp 2.5.0 (2.5.0a0) <a2ccf04a940c23b34c33d7fe108d773e> /System/Library/Frameworks/ Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/ Python 0x49000 - 0x4bfff +libgpg-error.0.dylib ??? (???) /opt/local/ lib/libgpg-error.0.dylib 0xbb000 - 0xc2ff3 +libvirtmod.so ??? (???) <20dea38de64927c9e8b50a1fa240e067> /usr/local/lib/python2.5/site- packages/libvirtmod.so 0x118000 - 0x1e3ffb org.python.python 2.5 (2.5) <9786e5d8790a594bb7b3cdcf9a9d0b49> /System/Library/Frameworks/ Python.framework/Versions/2.5/Python 0x2f0000 - 0x2f7ff3 +libintl.8.dylib ??? (???) /opt/local/lib/ libintl.8.dylib 0x400000 - 0x424fef +libvirt.0.dylib ??? (???) <70af9029fa4c7accc04377f0f65c53ae> /usr/local/lib/libvirt.0.dylib 0x43b000 - 0x49bfff +libgnutls.26.dylib ??? (???) /opt/local/lib/ libgnutls.26.dylib 0x4b5000 - 0x4c2fe2 +libtasn1.3.dylib ??? (???) /opt/local/lib/ libtasn1.3.dylib 0x4c7000 - 0x528ff3 +libgcrypt.11.dylib ??? (???) <76bad0ad90909bf99f422f8bbfd61124> /opt/local/lib/libgcrypt.11.dylib 0x540000 - 0x637ff0 +libiconv.2.dylib ??? (???) /opt/local/lib/ libiconv.2.dylib 0x644000 - 0x654ffd +libz.1.dylib ??? (???) /opt/local/lib/libz. 1.dylib 0x65f000 - 0x661ffc apop.so ??? (???) <8e5cbfa49bbed80ed34f03e008e3e086> /usr/lib/sasl2/apop.so 0x665000 - 0x67dfe2 dhx.so ??? (???) <0831cf2893deaa2b5525ea7bfda17404> /usr/lib/sasl2/dhx.so 0x68c000 - 0x694fff digestmd5WebDAV.so ??? (???) <42e13c06e037f02eee71a43324169f62> /usr/lib/sasl2/digestmd5WebDAV.so 0x698000 - 0x69afff libanonymous.2.so ??? (???) <161902c9ed78dce78b61125c7c155f0f> /usr/lib/sasl2/libanonymous.2.so 0x69e000 - 0x6a0ffc libcrammd5.2.so ??? (???) <c917c89eefddcfcacf48c939c3af12aa> /usr/lib/sasl2/libcrammd5.2.so 0x6a4000 - 0x6adffb libdigestmd5.2.so ??? (???) <c8595204acd0e7cb362b33d008693019> /usr/lib/sasl2/libdigestmd5.2.so 0x6b1000 - 0x6b5fff libgssapiv2.2.so ??? (???) <a47ee23249e7c36aee418a6e7fd3a502> /usr/lib/sasl2/libgssapiv2.2.so 0x6bb000 - 0x6bdffc login.so ??? (???) <03d28ec908a6ed9abee1b25fe87716ef> /usr/lib/sasl2/login.so 0x6c1000 - 0x6c8ffc libotp.2.so ??? (???) <0b7c8cd165835331c586e49465ef1186> /usr/lib/sasl2/libotp.2.so 0x6d2000 - 0x6d4ffc libplain.2.so ??? (???) <5992f1149ff6cc7fadafa2bfd4ecc00a> /usr/lib/sasl2/libplain.2.so 0x6d8000 - 0x6ddffc libpps.so ??? (???) <ae02d7b23951bddb4db705b2d632c6ac> /usr/lib/sasl2/libpps.so 0x6e3000 - 0x6e6fff mschapv2.so ??? (???) <8d5951f3d3a0565fd772ebec4d2054fb> /usr/lib/sasl2/mschapv2.so 0x6ea000 - 0x6ecffc shadow_auxprop.so ??? (???) <5137115453406a92cf514b65046a6b28> /usr/lib/sasl2/shadow_auxprop.so 0x6f2000 - 0x6f4ffd smb_lm.so ??? (???) <e9ad275441e15388bf580b1cdf55b430> /usr/lib/sasl2/smb_lm.so 0x6f8000 - 0x6faffc smb_nt.so ??? (???) <a7144a88919b4aea313caf6c4e86353a> /usr/lib/sasl2/smb_nt.so 0x6fe000 - 0x701ff0 smb_ntlmv2.so ??? (???) <ccfa6d0eafa992db95ad309e32c6d400> /usr/lib/sasl2/smb_ntlmv2.so 0x8fe00000 - 0x8fe2d883 dyld 95.3 (???) <81592e798780564b5d46b988f7ee1a6a> /usr/lib/dyld 0x90d29000 - 0x90e5bfe7 com.apple.CoreFoundation 6.5 (476) <8bfebc0dbad6fc33bea0fa00a1b9ec37> /System/Library/Frameworks/ CoreFoundation.framework/Versions/A/CoreFoundation 0x90e5c000 - 0x90e7aff3 com.apple.DirectoryService.Framework 3.5 (3.5) <899d8c9ee31b004a6ff73dab88982b1a> /System/Library/Frameworks/ DirectoryService.framework/Versions/A/DirectoryService 0x922a3000 - 0x92353fff edu.mit.Kerberos 6.0.11 (6.0.11) <33c25789baedcd70a7e24881775dd9ad> /System/Library/Frameworks/ Kerberos.framework/Versions/A/Kerberos 0x9244f000 - 0x924acffb libstdc++.6.dylib ??? (???) <04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib 0x92510000 - 0x926d9fef com.apple.security 5.0.1 (32736) <8c9eda0fcc1d8a571543025ac900715f> /System/Library/Frameworks/ Security.framework/Versions/A/Security 0x92f62000 - 0x92f80fff libresolv.9.dylib ??? (???) <54e6a08c2f108bdf5916fb483d51961b> /usr/lib/libresolv.9.dylib 0x93661000 - 0x9366fffd libz.1.dylib ??? (???) <5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib 0x936a2000 - 0x93783ff7 libxml2.2.dylib ??? (???) <450ec38b57fb46013847cce851001a2f> /usr/lib/libxml2.2.dylib 0x93d28000 - 0x93d2ffe9 libgcc_s.1.dylib ??? (???) <f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib 0x94a5b000 - 0x94b93ff7 libicucore.A.dylib ??? (???) <afcea652ff2ec36885b2c81c57d06d4c> /usr/lib/libicucore.A.dylib 0x95a7f000 - 0x95b5efff libobjc.A.dylib ??? (???) <5eda47fec2d0e7853b3506aa1fd2dafa> /usr/lib/libobjc.A.dylib 0x9631e000 - 0x963d0ffb libcrypto.0.9.7.dylib ??? (???) <330b0e48e67faffc8c22dfc069ca7a47> /usr/lib/libcrypto.0.9.7.dylib 0x9642c000 - 0x9643bfff libsasl2.2.dylib ??? (???) <b9e1ca0b6612e280b6cbea6df0eec5f6> /usr/lib/libsasl2.2.dylib 0x9643c000 - 0x96466fef libauto.dylib ??? (???) <d468bc4a8a69343f1748c293db1b57fb> /usr/lib/libauto.dylib 0x96d8c000 - 0x96d8dfef libmathCommon.A.dylib ??? (???) /usr/lib/ system/libmathCommon.A.dylib 0x96d9a000 - 0x96ef4fe3 libSystem.B.dylib ??? (???) <8ecc83dc0399be3946f7a46e88cf4bbb> /usr/lib/libSystem.B.dylib 0xfffe8000 - 0xfffebfff libobjc.A.dylib ??? (???) /usr/lib/ libobjc.A.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/ libSystem.B.dylib
- -- - -a
On Jan 22, 2008, at 6:41 AM, Richard W.M. Jones wrote:
Richard W.M. Jones wrote:
* PKG_CHECK_EXISTS macro doesn't exist and has to be commented out everywhere. This is despite the fact that I have pkg-config from Macports installed.
Looking into this in a bit more detail -- Macports installs everything under /opt/local and there is a pkg.m4 file under there which contains PKG_CHECK_EXISTS macro:
$ grep PKG_CHECK_EXISTS /opt/local/share/aclocal/pkg.m4 # PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) # PKG_CHECK_EXISTS manually AC_DEFUN([PKG_CHECK_EXISTS], PKG_CHECK_EXISTS([$3],
What do I need to do to make autoconf use this macro? At the moment autoconf leaves the macro unexpanded, and as a result ./ configure fails.
checking for iptables... /sbin/iptables ./configure: line 35741: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35741: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
Rich.
-- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHlef9Tg8lceyAqqQRAmf7AJ4ikQJW/JjuWABbym07GuUWqdSe6gCgmpyD znJiL5O+1FBs6yd8NMFpqsY= =OutF -----END PGP SIGNATURE-----
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlgpfTg8lceyAqqQRArIHAJ9jC5iXWCU/6gHL6jektD07eSpBcQCg4sOU exIBCKc3M5J+keHP33OTv88= =2tg0 -----END PGP SIGNATURE-----
Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'd like to figure out why the exception is getting thrown. I built it from HEAD, and I still cannot connect. Do we still think this ties back to the XDR problems?
Have you by any chance replaced all "hyper" in remote_protocol.x with "long"? Because that changes the protocol, so it's unlikely anything will work. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did that originally, but since rebuilt it with a clean file (inserting the xdr.h header as I said) and it built. Then I tried connecting and it fails. - -- - -a On Jan 22, 2008, at 9:25 AM, Richard W.M. Jones wrote:
Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to figure out why the exception is getting thrown. I built it from HEAD, and I still cannot connect. Do we still think this ties back to the XDR problems?
Have you by any chance replaced all "hyper" in remote_protocol.x with "long"? Because that changes the protocol, so it's unlikely anything will work.
Rich.
-- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlgxRTg8lceyAqqQRAhoXAJ0csFM52Orvp4NxzVevvno7/lnoWQCfcXbj cVBbWwrxed0pcmOb6FBxAJA= =a5Py -----END PGP SIGNATURE-----
Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I did that originally, but since rebuilt it with a clean file (inserting the xdr.h header as I said) and it built. Then I tried connecting and it fails.
I can't reproduce this here. For me, it isn't sufficient just to add #include <rpc/xdr.h> to remote_protocol.h. xdr_quad_t is still undefined, which is not really surprising because it doesn't exist in any Mac OS X header file. I suspect that your remote_protocol.[ch] files are out of date -- built using the faulty "long" version of remote_protocol.x, and if you try to rebuild them you'll get the error that Mac OS X doesn't support "hyper". Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Tue, Jan 22, 2008 at 03:37:05PM +0000, Richard W.M. Jones wrote:
Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I did that originally, but since rebuilt it with a clean file (inserting the xdr.h header as I said) and it built. Then I tried connecting and it fails.
I can't reproduce this here. For me, it isn't sufficient just to add #include <rpc/xdr.h> to remote_protocol.h. xdr_quad_t is still undefined, which is not really surprising because it doesn't exist in any Mac OS X header file. I suspect that your remote_protocol.[ch] files are out of date -- built using the faulty "long" version of remote_protocol.x, and if you try to rebuild them you'll get the error that Mac OS X doesn't support "hyper".
The funny thing is that Apple clearly documents xdr_hyper in their manpages http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/xdr.... which lead me to think perhaps its just the rpcgen program of theirs that is broken ? Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I concur. The types are clearly defined in /usr/include/rpc/xdr.h. - -- - -a On Jan 22, 2008, at 9:47 AM, Daniel P. Berrange wrote:
On Tue, Jan 22, 2008 at 03:37:05PM +0000, Richard W.M. Jones wrote:
Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I did that originally, but since rebuilt it with a clean file (inserting the xdr.h header as I said) and it built. Then I tried connecting and it fails.
I can't reproduce this here. For me, it isn't sufficient just to add #include <rpc/xdr.h> to remote_protocol.h. xdr_quad_t is still undefined, which is not really surprising because it doesn't exist in any Mac OS X header file. I suspect that your remote_protocol.[ch] files are out of date -- built using the faulty "long" version of remote_protocol.x, and if you try to rebuild them you'll get the error that Mac OS X doesn't support "hyper".
The funny thing is that Apple clearly documents xdr_hyper in their manpages
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/xdr....
which lead me to think perhaps its just the rpcgen program of theirs that is broken ?
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/ ~danberr/ -=| |=- Projects: http://freshmeat.net/ ~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlhBtTg8lceyAqqQRApHdAJ99kLrOUGEaovlwXtsdUhKEgDBGkgCeJ/3p tJLD70x8Got9IUr0/EV6Uqw= =mBYN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You are correct, it was using the old build that I had installed, which I had changed to 'long'. Grrrr. So, perhaps if we can get the XDR stuff to work, libvirt will work too. - -- - -a On Jan 22, 2008, at 9:37 AM, Richard W.M. Jones wrote:
Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did that originally, but since rebuilt it with a clean file (inserting the xdr.h header as I said) and it built. Then I tried connecting and it fails.
I can't reproduce this here. For me, it isn't sufficient just to add #include <rpc/xdr.h> to remote_protocol.h. xdr_quad_t is still undefined, which is not really surprising because it doesn't exist in any Mac OS X header file. I suspect that your remote_protocol. [ch] files are out of date -- built using the faulty "long" version of remote_protocol.x, and if you try to rebuild them you'll get the error that Mac OS X doesn't support "hyper".
Rich.
-- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlhFBTg8lceyAqqQRAjExAJ40/QqQ5OwpHwmETD0oSk8+eYU3swCfY/rC O8Zws0ATHwputFkEb0s7CQo= =Xx5o -----END PGP SIGNATURE-----
Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
You are correct, it was using the old build that I had installed, which I had changed to 'long'. Grrrr. So, perhaps if we can get the XDR stuff to work, libvirt will work too.
Don't worry - I'm just now porting the Windows XDR library that I "wrote"[*] to run on Macs. Rich. [*] really "cobbled together" -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I cannot for the life of me find the rpcgen source. I thought maybe if I could get it to recompile on OS X I could build it with hyper support. - -- - -a On Jan 22, 2008, at 9:50 AM, Richard W.M. Jones wrote:
Schley Andrew Kutz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You are correct, it was using the old build that I had installed, which I had changed to 'long'. Grrrr. So, perhaps if we can get the XDR stuff to work, libvirt will work too.
Don't worry - I'm just now porting the Windows XDR library that I "wrote"[*] to run on Macs.
Rich.
[*] really "cobbled together"
-- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHlhJMTg8lceyAqqQRAndmAKCKlEMRYd9TjpPi0eG8FsYbK15e3gCgqFcE nV+naZZfrPvSM3ILhgEBXds= =bybR -----END PGP SIGNATURE-----
Schley Andrew Kutz wrote:
I cannot for the life of me find the rpcgen source. I thought maybe if I could get it to recompile on OS X I could build it with hyper support.
There's a million different versions of the RPC tools, all derived from some source that Sun released into the wild back in the late 1980's. "rpcgen" itself needs a rewrite so it is based on a real lex/yacc parser, and not a hand-written string munger done in C as it is at the moment. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
"Richard W.M. Jones" <rjones@redhat.com> wrote:
Richard W.M. Jones wrote:
* PKG_CHECK_EXISTS macro doesn't exist and has to be commented out everywhere. This is despite the fact that I have pkg-config from Macports installed.
Looking into this in a bit more detail -- Macports installs everything under /opt/local and there is a pkg.m4 file under there which contains PKG_CHECK_EXISTS macro:
$ grep PKG_CHECK_EXISTS /opt/local/share/aclocal/pkg.m4 # PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) # PKG_CHECK_EXISTS manually AC_DEFUN([PKG_CHECK_EXISTS], PKG_CHECK_EXISTS([$3],
What do I need to do to make autoconf use this macro? At the moment autoconf leaves the macro unexpanded, and as a result ./configure fails.
checking for iptables... /sbin/iptables ./configure: line 35741: syntax error near unexpected token libxml-2.0,LIBXML_FOUND=yes' ./configure: line 35741: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)'
Hi Rich, So, you have this file, /opt/local/share/aclocal/pkg.m4 yet your version of aclocal doesn't find it. This should be enough to make it work: mkdir -p $(aclocal --print-ac-dir) echo /opt/local/share/aclocal >> $(aclocal --print-ac-dir)/dirlist
Jim Meyering wrote:
So, you have this file,
/opt/local/share/aclocal/pkg.m4
yet your version of aclocal doesn't find it. This should be enough to make it work:
mkdir -p $(aclocal --print-ac-dir) echo /opt/local/share/aclocal >> $(aclocal --print-ac-dir)/dirlist
OK, that got PKG_CHECK_EXISTS fine. To be precise I had to do: echo /opt/local/share/aclocal >> $(aclocal --print-ac-dir)/dirlist aclocal -I m4 -I gnulib/m4 automake autoconf CFLAGS=-I/opt/local/include \ LDFLAGS=-L/opt/local/lib \ ./configure --without-xen --without-qemu For reasons which are unclear gl_COMPILER_FLAGS macro is not copied into aclocal.m4. I think autom4te is refusing to believe that this macro is used, even though it's clearly in configure.in, but I didn't spend too long trying to delve into the internal machinations of autom4te. Instead I just commented out the two references to gl_COMPILER_FLAGS. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
"Richard W.M. Jones" <rjones@redhat.com> wrote:
Attached is as far as I got over the weekend.
As you can see the main problems (apart from the lack of hyper which is a showstopper) are:
* Minor header tweaks ... Index: src/sexpr.c =================================================================== RCS file: /data/cvs/libvirt/src/sexpr.c,v retrieving revision 1.12 diff -u -r1.12 sexpr.c --- src/sexpr.c 21 Jan 2008 14:22:15 -0000 1.12 +++ src/sexpr.c 22 Jan 2008 12:24:37 -0000 @@ -13,7 +13,7 @@ #include "config.h"
#include <stdio.h> -#include <malloc.h> +#include <stdlib.h>
Hi Rich, That one looks like an improvement, regardless. If you're removing <malloc.h> there, I'll bet it makes sense to do the same to the only other use, which is in xend_internal.c. It already includes <stdlib.h>.
participants (5)
-
Daniel P. Berrange -
Daniel Veillard -
Jim Meyering -
Richard W.M. Jones -
Schley Andrew Kutz