more comfortable approach for exporting dbus functions on windows

Ralf Habacker ralf.habacker at freenet.de
Thu Mar 4 14:32:59 PST 2010


Am 04.03.2010 22:51, schrieb Colin Walters:
> On Thu, Mar 4, 2010 at 4:33 PM, Ralf Habacker<ralf.habacker at freenet.de>  wrote:
>
>    
>> On windows the macro DBUS_EXPORT contains the required compiler directive to
>> export/import symbols, on non windows os this macro is a noop.
>>      
> I haven't looked at the patch, but I'm relatively OK with this.  I'd
> suggest this text for the comment:
>
> /*
>   * Declare the following symbol as public.  This is currently a noop on
>   * platforms other than Windows.
>   */
>
>    
thanks for this hint
> Related to this, one thing we should actually really investigate is
> the trick used in GLib to avoid going through the PLT for internal
> functions.  See: http://git.gnome.org/browse/glib/tree/glib/makegalias.pl
>    
I'm not sure if the reason why there is a also visibility attribute in 
KDE is the same as described above.
If it is symbol visibility on non windows os  we can do the following 
similar to what is implemented in KDE for example in

http://websvn.kde.org/trunk/KDE/kdelibs/kdemacros.h.cmake?view=markup
and 
http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/kdecore_export.h?view=markup

#ifdef DBUS_HAVE_GCC_VISIBILITY
#define DBUS_NO_EXPORT __attribute__ ((visibility("hidden")))
#define _DBUS_EXPORT __attribute__ ((visibility("default")))
#define _DBUS_IMPORT __attribute__ ((visibility("default")))
#elif defined(_WIN32) || defined(_WIN64)
#define DBUS_NO_EXPORT
#define _DBUS_EXPORT __declspec(dllexport)
#define _DBUS_IMPORT __declspec(dllimport)
#else
#define DBUS_NO_EXPORT
#define _DBUS_EXPORT
#define _DBUS_IMPORT
#endif

#ifndef DBUS_EXPORT
# if defined(dbus_1_EXPORTS)
/* We are building this library */
# define DBUS_EXPORT _DBUS_EXPORT
# else
/* We are using this library */
# define DBUS_EXPORT _DBUS_IMPORT
# endif
#endif

> But that's probably a different patch.
yes, because it may require to use the DBUS_NO_EXPORT macro, see also 
below.
>> The appended patch adds such support for the public dbus api functions. The
>> internal symbols could be adressed in further patches.
>>      
> What change would need to be made to the internal symbols?
>    
to be clear - i used the term internal for dbus internal functions 
indicated by the _dbus prefix, which are also exported from dbus-1 
shared library.

Symbols which are not exported do not need any decoration on windows, 
because this is the default. if gcc on unix has a switch to set the 
default symbol visibility to 'hidden', than there is also no decoration 
required for this case. Otherwise the above mentioned DBUS_NO_EXPORT 
could be used for this case.

To export the dbus internal functions the following steps are required:

1. add DBUS_EXPORT to  _dbus_... function
2. remove related symbolnames from xxx.def.in

When all symbols are decorated the .def file creation and usage could be 
removed in the autotools and cmake build system.

Regards



More information about the dbus mailing list