I got a little bit further with this, my current patch is attached. At the moment, it gets as far as building libvirt & virsh, but fails to build the Python bindings. However virsh doesn't run, apparently because of a simple dynamic linking problem because of where the libraries are (not yet) installed. I'm afraid that my understanding of how to build and install applications on Mac OS X ends around here. In particular I have no idea how to get the detailed abort trace that Andrew showed up in his previous email. References to portablexdr will be explained in a forthcoming email. 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
Just in case it wasn't clear, this patch is not to be applied. 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 Wed, Jan 23, 2008 at 01:23:56PM +0000, Richard W.M. Jones wrote:
Just in case it wasn't clear, this patch is not to be applied.
yes but some parts should IMHO, 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 Wed, Jan 23, 2008 at 01:21:29PM +0000, Richard W.M. Jones wrote:
I got a little bit further with this, my current patch is attached.
At the moment, it gets as far as building libvirt & virsh, but fails to build the Python bindings. However virsh doesn't run, apparently because of a simple dynamic linking problem because of where the libraries are (not yet) installed. I'm afraid that my understanding of how to build and install applications on Mac OS X ends around here. In particular I have no idea how to get the detailed abort trace that Andrew showed up in his previous email.
maybe some parts of it should be checked in purely as cleanup/portability enhancement, see comment below
dnl Availability of various common headers (non-fatal if missing). AC_CHECK_HEADERS([pwd.h paths.h sys/syslimits.h sys/utsname.h sys/wait.h winsock2.h])
-dnl Need -lrpc or -lxdr? (Cygwin and MinGW resp. need this) -AC_SEARCH_LIBS(xdrmem_create,[rpc xdr]) +dnl Where are the XDR functions? +dnl If portablexdr is installed, prefer that. +dnl Otherwise try -lrpc (Cygwin) -lxdr (some MinGW) or none (most Unix) +AC_CHECK_LIB([portablexdr],[xdrmem_create],[],[ + AC_SEARCH_LIBS([xdrmem_create],[rpc xdr]) + ])
Should be fine I think
dnl Do we have rpcgen? AC_PATH_PROG(RPCGEN, rpcgen, no) @@ -621,8 +625,8 @@ [enableval=no])
if test "${enableval}" = yes; then - gl_COMPILER_FLAGS(-fprofile-arcs) - gl_COMPILER_FLAGS(-ftest-coverage) + dnl gl_COMPILER_FLAGS(-fprofile-arcs) + dnl gl_COMPILER_FLAGS(-ftest-coverage)
We really shouldn't assume such recent features of gcc, I understand it's useful from for coverage reports, but it really can't get in the way for normal compilations, maybe this need to be refined a bit so that we can keep it. I would have assumed that if --enable-test-coverage wasn't explicitely asked for, then those bits would not need to be disabled, right ?
AC_SUBST([COVERAGE_CFLAGS], [$COMPILER_FLAGS]) AC_SUBST([COVERAGE_LDFLAGS], [$COMPILER_FLAGS]) COMPILER_FLAGS= Index: qemud/internal.h =================================================================== RCS file: /data/cvs/libvirt/qemud/internal.h,v retrieving revision 1.41 diff -u -r1.41 internal.h --- qemud/internal.h 5 Dec 2007 18:21:27 -0000 1.41 +++ qemud/internal.h 23 Jan 2008 13:21:42 -0000 @@ -25,6 +25,10 @@ #ifndef QEMUD_INTERNAL_H__ #define QEMUD_INTERNAL_H__
+#include <config.h> + +#include "../src/socketcompat.h" + #include <gnutls/gnutls.h> #include <gnutls/x509.h> #include "../src/gnutls_1_0_compat.h" @@ -43,7 +47,6 @@ #include <rpc/types.h> #include <rpc/xdr.h> #include "remote_protocol.h" -#include "../config.h"
Looks like a good change
#ifdef __GNUC__ #ifdef HAVE_ANSIDECL_H Index: qemud/qemud.c =================================================================== RCS file: /data/cvs/libvirt/qemud/qemud.c,v retrieving revision 1.76 diff -u -r1.76 qemud.c --- qemud/qemud.c 11 Dec 2007 21:57:29 -0000 1.76 +++ qemud/qemud.c 23 Jan 2008 13:21:43 -0000 @@ -47,6 +47,7 @@ #include <assert.h> #include <fnmatch.h> #include <grp.h> +#include <signal.h>
#include "libvirt/virterror.h" looks safe too
=================================================================== RCS file: /data/cvs/libvirt/src/Makefile.am,v retrieving revision 1.62 diff -u -r1.62 Makefile.am --- src/Makefile.am 5 Jan 2008 16:06:36 -0000 1.62 +++ src/Makefile.am 23 Jan 2008 13:21:44 -0000 @@ -66,7 +66,7 @@ libvirt_la_SOURCES = $(CLIENT_SOURCES) $(SERVER_SOURCES) libvirt_la_LIBADD = $(LIBXML_LIBS) $(GNUTLS_LIBS) $(SASL_LIBS) \ @CYGWIN_EXTRA_LIBADD@ ../gnulib/lib/libgnu.la -libvirt_la_LDFLAGS = -Wl,--version-script=$(srcdir)/libvirt_sym.version \ +libvirt_la_LDFLAGS = \ -version-info @LIBVIRT_VERSION_INFO@ \ $(COVERAGE_CFLAGS:-f%=-Wc,-f%) \ @CYGWIN_EXTRA_LDFLAGS@ @MINGW_EXTRA_LDFLAGS@
Hum, we really rely on libvirt_sym.version to define the exported list, someone may be able to help on how to do this on OS X, but as is we can't apply it seems.
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 23 Jan 2008 13:21:44 -0000 @@ -13,7 +13,7 @@ #include "config.h"
#include <stdio.h> -#include <malloc.h> +#include <stdlib.h> #include <string.h> #include <ctype.h> #include <errno.h>
portability++
Index: src/socketcompat.h =================================================================== RCS file: /data/cvs/libvirt/src/socketcompat.h,v retrieving revision 1.1 diff -u -r1.1 socketcompat.h --- src/socketcompat.h 5 Jan 2008 16:06:36 -0000 1.1 +++ src/socketcompat.h 23 Jan 2008 13:21:44 -0000 @@ -28,6 +28,7 @@ #ifndef HAVE_WINSOCK2_H /* Unix & Cygwin. */
#include <sys/socket.h> +#include <sys/un.h> #include <net/if.h> #include <netinet/in.h> #include <netinet/tcp.h>
we already include sys/un.h in xend_internal.c and proxy_internal.c so this can't break anything, looks safe. 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/
Daniel Veillard wrote:
dnl Do we have rpcgen? AC_PATH_PROG(RPCGEN, rpcgen, no) @@ -621,8 +625,8 @@ [enableval=no])
if test "${enableval}" = yes; then - gl_COMPILER_FLAGS(-fprofile-arcs) - gl_COMPILER_FLAGS(-ftest-coverage) + dnl gl_COMPILER_FLAGS(-fprofile-arcs) + dnl gl_COMPILER_FLAGS(-ftest-coverage)
We really shouldn't assume such recent features of gcc, I understand it's useful from for coverage reports, but it really can't get in the way for normal compilations, maybe this need to be refined a bit so that we can keep it. I would have assumed that if --enable-test-coverage wasn't explicitely asked for, then those bits would not need to be disabled, right ?
Yes, but unfortunately it doesn't work. Because gl_COMPILER_FLAGS isn't expanded in the output, ./configure fails even though the code is in a conditional arm. Bourne shell just can't parse it. The problem seems to come about because aclocal doesn't put gl_COMPILER_FLAGS into aclocal.m4, and that is apparently because autom4te doesn't believe that gl_COMPILER_FLAGS is really used. I don't know how to solve this -- I just commented it out so I could get it to work at all.
=================================================================== RCS file: /data/cvs/libvirt/src/Makefile.am,v retrieving revision 1.62 diff -u -r1.62 Makefile.am --- src/Makefile.am 5 Jan 2008 16:06:36 -0000 1.62 +++ src/Makefile.am 23 Jan 2008 13:21:44 -0000 @@ -66,7 +66,7 @@ libvirt_la_SOURCES = $(CLIENT_SOURCES) $(SERVER_SOURCES) libvirt_la_LIBADD = $(LIBXML_LIBS) $(GNUTLS_LIBS) $(SASL_LIBS) \ @CYGWIN_EXTRA_LIBADD@ ../gnulib/lib/libgnu.la -libvirt_la_LDFLAGS = -Wl,--version-script=$(srcdir)/libvirt_sym.version \ +libvirt_la_LDFLAGS = \ -version-info @LIBVIRT_VERSION_INFO@ \ $(COVERAGE_CFLAGS:-f%=-Wc,-f%) \ @CYGWIN_EXTRA_LDFLAGS@ @MINGW_EXTRA_LDFLAGS@
Hum, we really rely on libvirt_sym.version to define the exported list, someone may be able to help on how to do this on OS X, but as is we can't apply it seems.
Yeah, I don't know how to fix this yet on Mac OS X. It's possible we could just do some $host checking in ./configure and disable this bit of the command line for anything which matches *darwin*. I'll commit the non-controversial parts of this patch. 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 Wed, Jan 23, 2008 at 02:38:52PM +0000, Richard W.M. Jones wrote:
Daniel Veillard wrote:
dnl Do we have rpcgen? AC_PATH_PROG(RPCGEN, rpcgen, no) @@ -621,8 +625,8 @@ [enableval=no])
if test "${enableval}" = yes; then - gl_COMPILER_FLAGS(-fprofile-arcs) - gl_COMPILER_FLAGS(-ftest-coverage) + dnl gl_COMPILER_FLAGS(-fprofile-arcs) + dnl gl_COMPILER_FLAGS(-ftest-coverage)
We really shouldn't assume such recent features of gcc, I understand it's useful from for coverage reports, but it really can't get in the way for normal compilations, maybe this need to be refined a bit so that we can keep it. I would have assumed that if --enable-test-coverage wasn't explicitely asked for, then those bits would not need to be disabled, right ?
Yes, but unfortunately it doesn't work. Because gl_COMPILER_FLAGS isn't expanded in the output, ./configure fails even though the code is in a conditional arm. Bourne shell just can't parse it.
The problem seems to come about because aclocal doesn't put gl_COMPILER_FLAGS into aclocal.m4, and that is apparently because autom4te doesn't believe that gl_COMPILER_FLAGS is really used.
I don't know how to solve this -- I just commented it out so I could get it to work at all.
This definition comes from the m4/compilerflags.m4 file. You might want to try moving that stuff into 'acinclude.m4' instead. 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 Wed, Jan 23, 2008 at 09:33:04AM -0500, Daniel Veillard wrote:
On Wed, Jan 23, 2008 at 01:21:29PM +0000, Richard W.M. Jones wrote:
I got a little bit further with this, my current patch is attached.
At the moment, it gets as far as building libvirt & virsh, but fails to build the Python bindings. However virsh doesn't run, apparently because of a simple dynamic linking problem because of where the libraries are (not yet) installed. I'm afraid that my understanding of how to build and install applications on Mac OS X ends around here. In particular I have no idea how to get the detailed abort trace that Andrew showed up in his previous email.
maybe some parts of it should be checked in purely as cleanup/portability enhancement, see comment below
dnl Availability of various common headers (non-fatal if missing). AC_CHECK_HEADERS([pwd.h paths.h sys/syslimits.h sys/utsname.h sys/wait.h winsock2.h])
-dnl Need -lrpc or -lxdr? (Cygwin and MinGW resp. need this) -AC_SEARCH_LIBS(xdrmem_create,[rpc xdr]) +dnl Where are the XDR functions? +dnl If portablexdr is installed, prefer that. +dnl Otherwise try -lrpc (Cygwin) -lxdr (some MinGW) or none (most Unix) +AC_CHECK_LIB([portablexdr],[xdrmem_create],[],[ + AC_SEARCH_LIBS([xdrmem_create],[rpc xdr]) + ])
Should be fine I think
dnl Do we have rpcgen? AC_PATH_PROG(RPCGEN, rpcgen, no) @@ -621,8 +625,8 @@ [enableval=no])
if test "${enableval}" = yes; then - gl_COMPILER_FLAGS(-fprofile-arcs) - gl_COMPILER_FLAGS(-ftest-coverage) + dnl gl_COMPILER_FLAGS(-fprofile-arcs) + dnl gl_COMPILER_FLAGS(-ftest-coverage)
We really shouldn't assume such recent features of gcc, I understand it's useful from for coverage reports, but it really can't get in the way for normal compilations, maybe this need to be refined a bit so that we can keep it. I would have assumed that if --enable-test-coverage wasn't explicitely asked for, then those bits would not need to be disabled, right ?
The whole point of the gl_COMPILER_FLAGS macro is that it *tests* each flag to see if it is supported or not. So we won't end up using the flags if they're not supported by the compiler. I don't know what rich commented out this block ... ?
=================================================================== RCS file: /data/cvs/libvirt/src/Makefile.am,v retrieving revision 1.62 diff -u -r1.62 Makefile.am --- src/Makefile.am 5 Jan 2008 16:06:36 -0000 1.62 +++ src/Makefile.am 23 Jan 2008 13:21:44 -0000 @@ -66,7 +66,7 @@ libvirt_la_SOURCES = $(CLIENT_SOURCES) $(SERVER_SOURCES) libvirt_la_LIBADD = $(LIBXML_LIBS) $(GNUTLS_LIBS) $(SASL_LIBS) \ @CYGWIN_EXTRA_LIBADD@ ../gnulib/lib/libgnu.la -libvirt_la_LDFLAGS = -Wl,--version-script=$(srcdir)/libvirt_sym.version \ +libvirt_la_LDFLAGS = \ -version-info @LIBVIRT_VERSION_INFO@ \ $(COVERAGE_CFLAGS:-f%=-Wc,-f%) \ @CYGWIN_EXTRA_LDFLAGS@ @MINGW_EXTRA_LDFLAGS@
Hum, we really rely on libvirt_sym.version to define the exported list, someone may be able to help on how to do this on OS X, but as is we can't apply it seems.
Some linkers have different ways todo this - I don't see it as a huge issue if we can't filter this on Mac OS-X. This is just a layer of protection to discourage people who don't read docs. 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 -=|
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones