<table cellspacing="0" cellpadding="0" border="0"><tr><td valign="top" style="font: inherit;">I'm working on the instructions doc now. Thanks again. Sent from Yahoo! Mail on Android </td></tr></table> <div id="_origMsg_"> <div style="font-family:arial, helvetica, sans-serif:font-size:10pt"> <div style="font-family:times new roman, new york, times, serif;font-size:12pt"> <hr size="1"> From: Simon McVittie <simon.mcvittie@collabora.co.uk>; To: <dbus@lists.freedesktop.org>; Subject: Re: help linking to python for dbus-python bindings Sent: Thu, Jul 5, 2012 11:01:55 AM <table cellspacing="0" cellpadding="0" border="0"> <tbody> <tr> <td valign="top" style="font:inherit;">On 05/07/12 06:08, Mark Mikofski wrote: > *IT WORKS!* Good to know. I've merged the wip-windows branch, so the next dbus-python release will be similar to the snapshot you used. Since you are now the world's foremost expert on compiling dbus-python with mingw, would you mind writing a text file with instructions that can go in the doc directory? Instructions for compiling dbus-glib with mingw, or any patches you needed to use, would also be very welcome. > Also, I'm hopeful for the cmake build, because the win32 python is > build on msvc90, and uses that redist for extensions, altho > supposedly alt compilers can also be used (I've yet to test this - > but I guess mingw-gcc-4.7 works!). Of course this will pose another > issue for dbus-glib, which I haven't successfully built with msvc. I believe mixing compilers is normally only a problem if you share FILE objects across library boundaries (which dbus, dbus-glib and dbus-python don't), or if you use C++ (which those projects don't). So, you should be OK here. > Question on merging the cmake branch - have Ralf Habacker's KDE patches > [1] been merged? If nobody has told the bug tracker about them, then most likely no. > I guess maybe it would be nice to > have all of the windows ports sync'd upstream (as was done for dbus) so > there is a single source. If people who have forked it want this to happen, the first step is to put patches on the bug tracker for review. I do not periodically Google for "dbus-python patch" or anything like that :-) > Also, maybe I should have filed a bug, but I think it's an automake bug > in python.m4 [2] not in dbus-python. The command that finds the python > package directory, gets mangled on windows because it doesn't pad the > backslashes with an extra backslash, so everything get run together, > e.g. ${prefix}Libsite-packages, instead of > ${prefix}\\Lib\\site-packages. My fix is to edit the configure file and > add ".replace('\\\\\','/')" to those lines. Then it works on windows. That might be a bug in Automake, yes. You should be able to work around it by putting am_cv_python_pythondir on the configure command line, something like: ./configure [... other stuff ...] \ am_cv_python_pythondir='/opt/python/Lib/site-packages' (If you set a *_cv_* variable - a "cached value" - like this, Autoconf will trust what you say, and not do the automatic check it usually would.) > Also, I am still getting the following warnings during make: > > libtool: link: warning: undefined symbols not allowed in > i686-pc-mingw32 sharedlibraries If it otherwise works, this warning is probably harmless. If there are undefined symbols in the extension, I'd need to know which symbols they are (preferably on a bug report). S _______________________________________________ dbus mailing list <a ymailto="mailto:dbus@lists.freedesktop.org" href="javascript:return">dbus@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/dbus" target=_blank >http://lists.freedesktop.org/mailman/listinfo/dbus</a> </td> </tr> </tbody> </table> </div> </div> </div>