more comfortable approach for exporting dbus functions on windows

Romain Pokrzywka romain at
Mon Mar 22 15:24:00 PDT 2010


I've tested the patch and it works fine.
Thanks a lot for this, and for the additional cleanup, this was really a big step for getting a cleaner code base on 
windows !
(just one thing: you could have checked with me with the status for that task before, as I said that I intended to work 
on it. That was luck that I didn't have time yet, otherwise we would have effectively been doing the same thing twice 

Otherwise, this is unrelated to your patch, but after the latest dbus-1.2 merge an obsolete test was removed from the 
source so the CMakeLists.txt needs to be adjusted. The fix is attached, can be committed safely.


On Monday 22 March 2010 03:21:03 Ralf Habacker wrote:
> Ralf Habacker schrieb:
> > 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.
> ... which could be fixed later, if really required.
> Appended are the related patches for the cmake buildsystem - I tested it
> with msvc and mingw on windows without any problems.
> If there are no objections I will commit them tomorrow.
> The required patches for the autotools build system should cover the
> following topics:
> 1. remove def file usage and installation in buildsystem (including the
> .def.* files from dbus/ source dir)
> 2. add -DDBUS_STATIC_BUILD to the compile flags for building the
> dbus-internal target.
> 3. add -DDBUS_STATIC_BUILD to the compile flags for building all targets
> which depends on the internal lib (or dbus-convenience as it is called
> on unix)
> Ralf

Romain Pokrzywka | romain at | Certified Qt Software Engineer & Trainer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-remove-name-test2-from-cmake.patch
Type: text/x-patch
Size: 1143 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the dbus mailing list