10:47 a.m.
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
10:58 a.m.
New subject: [Libvir] [PATCH 1/3] configure.in compiler and enable libtool DLLs
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
11:12 a.m.
New subject: [Libvir] [PATCH 1/3] configure.in compiler and enable libtool DLLs
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
1:23 p.m.
New subject: [Libvir] [PATCH 1/3] configure.in compiler and enable libtool DLLs
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 -=|
10:58 a.m.
New subject: [Libvir] [PATCH 2/3] Cygwin-specific LDFLAGS and LIBADD
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
11:20 a.m.
New subject: [Libvir] [PATCH 2/3] Cygwin-specific LDFLAGS and LIBADD
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:21 a.m.
New subject: [Libvir] [PATCH 2/3] Cygwin-specific LDFLAGS and LIBADD
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
1:26 p.m.
New subject: [Libvir] [PATCH 2/3] Cygwin-specific LDFLAGS and LIBADD
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 -=|
10:58 a.m.
New subject: [Libvir] [PATCH 3/3] Python cygvirtmod.dll -> libvirtmod.dll
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
11:30 a.m.
New subject: [Libvir] [PATCH 3/3] Python cygvirtmod.dll -> libvirtmod.dll
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:34 a.m.
New subject: [Libvir] [PATCH 3/3] Python cygvirtmod.dll -> libvirtmod.dll
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
1:28 p.m.
New subject: [Libvir] [PATCH 3/3] Python cygvirtmod.dll -> libvirtmod.dll
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 -=|
1:46 p.m.
New subject: [Libvir] [PATCH 3/3] Python cygvirtmod.dll -> libvirtmod.dll
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
1:46 p.m.
New subject: [Libvir] [PATCH 3/3] Python cygvirtmod.dll -> libvirtmod.dll
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
9:41 p.m.
New subject: [Libvir] [PATCH 3/3] Python cygvirtmod.dll -> libvirtmod.dll
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
1:58 a.m.
New subject: [Libvir] [PATCH 3/3] Python cygvirtmod.dll -> libvirtmod.dll
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6231
days inactive
6232
days old
15 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
David Mueller -
Richard W.M. Jones