help linking to python for dbus-python bindings

Mark Mikofski bwanamarko at
Fri Jul 20 18:07:58 PDT 2012

updated again with autolaunch so that dbus works and dbus-python doesn't throw exceptions.

They are attached the this ticket: 

Mark Mikofski

 From: Mark Mikofski <bwanamarko at>
To: "dbus at lists freedesktop. org" <dbus at>; "simon.mcvittie at" <simon.mcvittie at> 
Sent: Sunday, July 8, 2012 10:51 AM
Subject: Re: help linking to python for dbus-python bindings

I attached instructions to install dbus-python on windows using mingw32 for review to this ticket: 

Sent from Yahoo! Mail on Android 

Sent from Yahoo! Mail on Android 

 From:  Simon McVittie <simon.mcvittie at>; 
To:  <dbus at>; 
Subject:  Re: help linking to python for dbus-python bindings 
Sent:  Thu, Jul 5, 2012 11:01:55 AM 

On 05/07/12 06:08, Mark Mikofski wrote:

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.

 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 ...] \

(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).

dbus mailing list
dbus at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the dbus mailing list