more comfortable approach for exporting dbus functions on windows

Ralf Habacker ralf.habacker at
Wed Mar 17 23:49:58 PDT 2010

Romain Pokrzywka schrieb:
> On Wednesday 17 March 2010 03:39:21 Ralf Habacker wrote:
>> Romain Pokrzywka schrieb:
>>> Hi,
>>> Sorry for the late reply on this one. Since it's been committed upstream
>>> in the meantime, I've had some time to try it out and it worked fine with
>>> msvc and mingw.
>>> But I think in its current form the change is of limited benefit, as it
>>> only applies to the public API functions: the real advantage of using the
>>> export macros is that it would finally allow getting rid of the .def
>>> files, which have been causing so much trouble lately and still are a
>>> nightmare for portability (see my patch on the next mail...). But for
>>> that we need to use the export macros on all the functions, including the
>>> non-public ones used for the tools and the internal library, basically
>>> every one that we have in the files currently. The principle is
>>> exactly the same, the same macro can be used, and nothing would change
>>> ABI-wise, it's just a lot more files and lines to edit :) I think it's
>>> worth the effort though.
>> just a few notes:
>> 1. on unix the dbus-1 library contains only the public symbols, on
>> windows dbus-1 library contains public and some internal symbols yet
>> 2. on unix dbus-internal library is static and contains all public and
>> internal symbols, on windows dbus-internal currently only contains all
>> symbols not listed in topic 1.
>> 3. on unix dbus-daemon, helper tools and tests apps depends on
>> dbus-internal only, on windows these apps depends on dbus-1 and
>> dbus-internal
>> 4. it may be required to export the same set of symbols on unix and
>> windows in dbus-1 and dbus-internal library before decoration for
>> internal functions could be added
>> 5. dbus-internal library is a separate build target and functions in
>> this library could not use  DBUS_EXPORT as export decoration, it should
>> have a different name for example DBUS_INTERNAL_EXPORT.
>>> I take care of that tomorrow, unless somebody objects.
>> feel free - if you need some assistance let me know.
>> Ralf
> Ah, thanks for that ! That's very valuable info, and indeed the first step would be to make the windows binaries and 
> build match the linux one. This is very easy as well, it's just about including the files from the client lib in the 
> internal one, and removing the linking to dbus-1 afterwards, that should take me less than an hour to do.
> As an added benefit, then we don't even need the second set of exports for internal symbols, since dbus-internal is 
> static. It would only be needed if we wanted to make it dynamic, which isn't really a necessity atm.
The only drawback with having a static internal library is that it is 
included in every helper tool and will blow up the binary package 
compressed and binary package installed size.


More information about the dbus mailing list