[Libvir] [PATCH 0/3] More misc patches to improve Windows support
There follows some miscellaneous patches to configure.in and the Makefile.am's to improve Windows support. I'll explain each in the follow-ups. 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
In this patch what I've done is to move the checks for C compiler and checks for programs apart from each other. We check for the C compiler first, then check for external programs later. This is just a cleanup. I've added AC_LIBTOOL_WIN32_DLL which enables DLL support in libtool (but shouldn't affect any other platform). I've added AM_PROG_CC_STDC which appears to be required by the above. I've added AC_C_CONST which is needed because libvirt uses 'const' without taking any special precautions for ancient compilers which don't support it. 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 Thu, Nov 29, 2007 at 04:58:26PM +0000, Richard W.M. Jones wrote:
In this patch what I've done is to move the checks for C compiler and checks for programs apart from each other. We check for the C compiler first, then check for external programs later. This is just a cleanup.
I've added AC_LIBTOOL_WIN32_DLL which enables DLL support in libtool (but shouldn't affect any other platform).
I've added AM_PROG_CC_STDC which appears to be required by the above.
I've added AC_C_CONST which is needed because libvirt uses 'const' without taking any special precautions for ancient compilers which don't support it.
Looks fine to me, +1 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 Thu, Nov 29, 2007 at 04:58:26PM +0000, Richard W.M. Jones wrote:
In this patch what I've done is to move the checks for C compiler and checks for programs apart from each other. We check for the C compiler first, then check for external programs later. This is just a cleanup.
I've added AC_LIBTOOL_WIN32_DLL which enables DLL support in libtool (but shouldn't affect any other platform).
I've added AM_PROG_CC_STDC which appears to be required by the above.
I've added AC_C_CONST which is needed because libvirt uses 'const' without taking any special precautions for ancient compilers which don't support it.
I didn't think any such lame compilers still existed in real world ;-) But, ACK. 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 -=|
Cygwin requires some extra LDFLAGS and LIBADD be passed when linking. Rather than add these extra flags to all invocations, I've created special @CYGWIN_EXTRA_*@ symbols to contain them. This is basically copied from libxml2. Also ordering of *_LIBADD and *_LDFLAGS seems to be important in automake. Specifically: if libvirt_la_SOURCES comes after libvirt_la_LDFLAGS then automake wasn't able to determine the list of sources (I've no idea why but possibly because libvirt_la_SOURCES is defined in terms of other variables?), so I've reordered these lines. 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 Thu, Nov 29, 2007 at 04:58:33PM +0000, Richard W.M. Jones wrote:
Cygwin requires some extra LDFLAGS and LIBADD be passed when linking. Rather than add these extra flags to all invocations, I've created special @CYGWIN_EXTRA_*@ symbols to contain them.
This is basically copied from libxml2.
well so this should have got some testing :-)
Also ordering of *_LIBADD and *_LDFLAGS seems to be important in automake. Specifically: if libvirt_la_SOURCES comes after libvirt_la_LDFLAGS then automake wasn't able to determine the list of sources (I've no idea why but possibly because libvirt_la_SOURCES is defined in terms of other variables?), so I've reordered these lines.
Sounds fine,
Index: src/Makefile.am =================================================================== RCS file: /data/cvs/libvirt/src/Makefile.am,v retrieving revision 1.55 diff -u -r1.55 Makefile.am --- src/Makefile.am 17 Nov 2007 11:17:48 -0000 1.55 +++ src/Makefile.am 29 Nov 2007 16:43:23 -0000 [...] @@ -64,6 +59,13 @@ ../qemud/remote_protocol.c ../qemud/remote_protocol.h
libvirt_la_SOURCES = $(CLIENT_SOURCES) $(SERVER_SOURCES) +libvirt_la_LIBADD = $(LIBXML_LIBS) $(GNUTLS_LIBS) $(LTLIBOBJS) \
What is LTLIBOBJS ? I don't remember this being added in the previous patch it shows up in the Makefiles but where does it comes from ?
+ @CYGWIN_EXTRA_LIBADD@ +libvirt_la_LDFLAGS = -Wl,--version-script=$(srcdir)/libvirt_sym.version \ + -version-info @LIBVIRT_VERSION_INFO@ \ + $(COVERAGE_CFLAGS:-f%=-Wc,-f%) \ + @CYGWIN_EXTRA_LDFLAGS@ +libvirt_la_CFLAGS = $(COVERAGE_CFLAGS)
bin_PROGRAMS = virsh
Just wondering about the above but that looks fine to me. Windows pythn bindings outside of cygwin can be a bit painful in practice 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:
+libvirt_la_LIBADD = $(LIBXML_LIBS) $(GNUTLS_LIBS) $(LTLIBOBJS) \
What is LTLIBOBJS ? I don't remember this being added in the previous patch it shows up in the Makefiles but where does it comes from ?
Sorry, that's a part of the getaddrinfo patch which snuck in there. It doesn't actually affect building, but I'll remove it before committing. 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 Thu, Nov 29, 2007 at 04:58:33PM +0000, Richard W.M. Jones wrote:
Cygwin requires some extra LDFLAGS and LIBADD be passed when linking. Rather than add these extra flags to all invocations, I've created special @CYGWIN_EXTRA_*@ symbols to contain them.
This is basically copied from libxml2.
Also ordering of *_LIBADD and *_LDFLAGS seems to be important in automake. Specifically: if libvirt_la_SOURCES comes after libvirt_la_LDFLAGS then automake wasn't able to determine the list of sources (I've no idea why but possibly because libvirt_la_SOURCES is defined in terms of other variables?), so I've reordered these lines.
ACK, but can we use $(CYGWIN_EXTRA_LIBADD) instead of @CYGWIN_EXTRA_LIBADD@ since the former is the style used by the other _LIBADD variables we set from configure 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 -=|
Cygwin likes to name DLLs as cyg<name>.dll. This is very unhelpful for Python loadable modules because the init function name will be wrong and because it requires a change to the 'libvirt.py' file to load the right module name (import libvirtmod -> import cygvirtmod). In this patch I've added a post-install hook to make a symlink so that Python finds libvirtmod.dll and all is happy. 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 Thu, Nov 29, 2007 at 04:58:42PM +0000, Richard W.M. Jones wrote:
Cygwin likes to name DLLs as cyg<name>.dll.
This is very unhelpful for Python loadable modules because the init function name will be wrong and because it requires a change to the 'libvirt.py' file to load the right module name (import libvirtmod -> import cygvirtmod).
hum, I think it would also require a change to the python C file to rename the entry point too, otherwise a simple try: import libvirtmod except: import cygvirtmod might have done it.
In this patch I've added a post-install hook to make a symlink so that Python finds libvirtmod.dll and all is happy.
I must admit I'm wondering a bit about ln -s reliability in a Windows environment ... maybe the above try:/except: plus a change at the end of python/libvir.c adding #ifdef CYGWIN void initcygvirtmod(void) { initlibvirtmod(); } #endif might be a bit more reliable, But if the current solution works :-) fine by me +1 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:
On Thu, Nov 29, 2007 at 04:58:42PM +0000, Richard W.M. Jones wrote:
Cygwin likes to name DLLs as cyg<name>.dll.
This is very unhelpful for Python loadable modules because the init function name will be wrong and because it requires a change to the 'libvirt.py' file to load the right module name (import libvirtmod -> import cygvirtmod).
hum, I think it would also require a change to the python C file to rename the entry point too, otherwise a simple try: import libvirtmod except: import cygvirtmod
might have done it.
In this patch I've added a post-install hook to make a symlink so that Python finds libvirtmod.dll and all is happy.
I must admit I'm wondering a bit about ln -s reliability in a Windows environment ... maybe the above try:/except: plus a change at the end of python/libvir.c adding
'ln -s' relies on Cygwin, which fakes it by writing a file called 'libvirtmod.dll.lnk' (or somesuch). So in some sense we require Cygwin, but of course all of this code needs Cygwin to function. Because this is Python the situation is arguably a little bit different. There are essentially two versions of Python for Windows -- one is a native port (compiled, presumably, with Visual C++), and the other is the Cygwin port which is the one that I'm using now. In theory I suppose a Cygwin-compiled Python module (*.dll) could be loaded by the native Python. It wouldn't work for us though because libvirtmod.dll requires cygvirt-0.dll which fundamentally requires Cygwin. We'd have to do a native version of libvirt as well, which involves lots of invasive changes.
#ifdef CYGWIN void initcygvirtmod(void) { initlibvirtmod(); } #endif
might be a bit more reliable,
Either would work -- whichever you feel happier with. 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 Thu, Nov 29, 2007 at 05:34:28PM +0000, Richard W.M. Jones wrote:
Daniel Veillard wrote:
On Thu, Nov 29, 2007 at 04:58:42PM +0000, Richard W.M. Jones wrote:
Cygwin likes to name DLLs as cyg<name>.dll.
#ifdef CYGWIN void initcygvirtmod(void) { initlibvirtmod(); } #endif
might be a bit more reliable,
Either would work -- whichever you feel happier with.
I think I'd prefer the compile time/python source change rather than symlinks. 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 Thu, Nov 29, 2007 at 07:28:32PM +0000, Daniel P. Berrange wrote:
On Thu, Nov 29, 2007 at 05:34:28PM +0000, Richard W.M. Jones wrote:
Daniel Veillard wrote:
On Thu, Nov 29, 2007 at 04:58:42PM +0000, Richard W.M. Jones wrote:
Cygwin likes to name DLLs as cyg<name>.dll.
#ifdef CYGWIN void initcygvirtmod(void) { initlibvirtmod(); } #endif
might be a bit more reliable,
Either would work -- whichever you feel happier with.
I think I'd prefer the compile time/python source change rather than symlinks.
Honnestly, me too :-) 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:
On Thu, Nov 29, 2007 at 07:28:32PM +0000, Daniel P. Berrange wrote:
On Thu, Nov 29, 2007 at 05:34:28PM +0000, Richard W.M. Jones wrote:
Daniel Veillard wrote:
On Thu, Nov 29, 2007 at 04:58:42PM +0000, Richard W.M. Jones wrote:
Cygwin likes to name DLLs as cyg<name>.dll.
#ifdef CYGWIN void initcygvirtmod(void) { initlibvirtmod(); } #endif
might be a bit more reliable, Either would work -- whichever you feel happier with. I think I'd prefer the compile time/python source change rather than symlinks.
Honnestly, me too :-)
As you may have seen I committed the symlink version, but I'll fix it tomorrow. Dan, same goes for your change from @CYGWIN_*@ -> ${CYGWIN_*} 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
Daniel Veillard wrote:
hum, I think it would also require a change to the python C file to rename the entry point too, otherwise a simple try: import libvirtmod except: import cygvirtmod
might have done it.
I would use try: import libvirtmod except: import cygvirtmod as libvirtmod as this avoids namespace problems with the rest of the code in the file. - David
On Thu, Nov 29, 2007 at 07:41:18PM -0800, David Mueller wrote:
Daniel Veillard wrote:
hum, I think it would also require a change to the python C file to rename the entry point too, otherwise a simple try: import libvirtmod except: import cygvirtmod
might have done it.
I would use
try: import libvirtmod except: import cygvirtmod as libvirtmod
as this avoids namespace problems with the rest of the code in the file.
oh, right, good point ! 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/
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
David Mueller -
Richard W.M. Jones