Windows DBus shared memory name depends on _DEBUG?

Ralf Habacker ralf.habacker at
Wed Sep 22 07:39:34 PDT 2010

  Am 22.09.2010 12:58, schrieb Thomas Sondergaard:
> On 22-09-2010 11:57, Ralf Habacker wrote:
>> Am 22.09.2010 11:06, schrieb Thomas Sondergaard:
>> This is guaranted by the autolaunch protocol. When using autolaunch
>> procotol in session bus config, dbus-daemon server automatically select
>> a free tcp port on localhost and saves this address in the related
>> shared memory segment. If the dbus client is configured using the
>> autolaunch protocol (which is the default on configure time) it fetches
>> the recent session dbus address from the related shared memory address.
>> Now debug and release builds could run independent dbus daemons.
> I'm a little confused by your answer. Let me ask a little differently: 
> Wouldn't it be best if debug and release builds using the default 
> autolaunch protocol would connect to the same bus?
I think this depends on the use case. In the KDE on windows context - 
where this implementation came from - this "feature" has been used to 
run a release build for daily work and an independent debug build. KDE 
uses dbus-daemon to start further applications and kioslaves. If there 
would only one daemon, debug applications would start slaves from 
release builds and vice versus, depending on which daemon has been 
started first. This makes debugging much harder.
Because of this limitations the mentioned patch is used for KDE as default.
>> One solution not to use the autolaunch procotol, another (probably
>> better solution) is applying the following patches
>> They remove the release and debug distinction of the shared memory
>> address and allows the user to specific a dedicated autolaunched bus by
>> using the following bus address for the daemon and the client:
>> autolaunch:scope=<term>
>> where term is either
>> 'install-path' to limit the bus to a specific install path or any other
>> term for other specific use cases.
>> With cmake this can be set on configure time by adding the following
>> define:
> Those changes sound good to me - why aren't they part of dbus?
At least there are some specification extensions required before as 
David mentioned  - I will see if i can find some time in the next days.


More information about the dbus mailing list