Mary hinton commented on PROTON-68:

I haven’t heard anything about adding the macros needed for dll imports and 
exports for a  Visual Studio port.

Cliff Jensen mention using the gcc switch –fvisibility=hidden, so I looked up 
what it does.

The online documentation states that this feature “can very substantially 
improve linking and load times of shared object libraries, produce more 
optimized code, provide near-perfect API export and prevent symbol clashes. It 
is strongly recommended that you use this in any shared objects you distribute.”

Tumentation also points you to other sources 
1)      Ulrich Drepper’s  paper:
“A good explanation of the benefits offered by ensuring ELF symbols have the 
correct visibility is given by “How To Write Shared Libraries” by Ulrich 
Drepper (which can be found at http://people.redhat.com/~drepper/)—however a 
superior solution made possible by this option to marking things hidden when 
the default is public is to make the default hidden and mark things public. 
This is the norm with DLL's on Windows and with -fvisibility=hidden and 
__attribute__ ((visibility("default"))) instead of __declspec(dllexport) you 
get almost identical semantics with identical syntax. This is a great boon to 
those working with cross-platform projects.”

“Export Control” starts on p. 17 of this paper by listing the drawbacks when 
you fail to restrict the set of exported symbols.
Not restricting the set of exported symbols is the default for gcc.

2)      http://gcc.gnu.org/wiki/Visibility

Visual Studio requires you to explicitly set what symbols and functions will be 
exported. The gcc shared libraries for proton would also be improved if we 
exported only the necessary functions and symbols, using the visibilty switch 
and the necessary shared library header file.

The wiki pages has a very good example of what is needed in their Step-by-step 
guide for Windows and GNU.

Here is the example listed for the header file needed:

// Generic helper definitions for shared library support
#if defined _WIN32 || defined __CYGWIN__
  #define FOX_HELPER_DLL_IMPORT __declspec(dllimport)
  #define FOX_HELPER_DLL_EXPORT __declspec(dllexport)
  #if __GNUC__ >= 4
    #define FOX_HELPER_DLL_IMPORT __attribute__ ((visibility ("default")))
    #define FOX_HELPER_DLL_EXPORT __attribute__ ((visibility ("default")))
    #define FOX_HELPER_DLL_LOCAL  __attribute__ ((visibility ("hidden")))

// Now we use the generic helper definitions above to define FOX_API and 
// FOX_API is used for the public API symbols. It either DLL imports or DLL 
exports (or does nothing for static build)
// FOX_LOCAL is used for non-api symbols.

#ifdef FOX_DLL // defined if FOX is compiled as a DLL
  #ifdef FOX_DLL_EXPORTS // defined if we are building the FOX DLL (instead of 
using it)
  #endif // FOX_DLL_EXPORTS
#else // FOX_DLL is not defined: this means FOX is a static lib.
  #define FX_API
  #define FOX_LOCAL
#endif // FOX_DLL

> Porting Issue -- dll imports and exports on Visual Studio
> ---------------------------------------------------------
>                 Key: PROTON-68
>                 URL: https://issues.apache.org/jira/browse/PROTON-68
>             Project: Qpid Proton
>          Issue Type: Improvement
>          Components: proton-c
>         Environment: Windows using Visual Studio 2010 
>            Reporter: Mary hinton
>              Labels: build
> Visual Studio dlls  use a macro to explicitly state which functions will be 
> exported. I don’t have a list of all the functions that will be exported, so 
> I just made the ones used by proton.c to be exportable. That left a lot that 
> would be internal to the dll only. Then when I was working with the python, I 
> realized that python was going to be importing a lot of functions from the 
> dll that should never be exported unless testing, so I defined another macro 
> for the python (ruby, etc) exported functions. Swig also had to be taken into 
> account. 
> This is what I’m using right now and it should work on the Linux/Unix 
> platform:
> #ifdef SWIGWIN
>        #define QPID_PROTON_API
> #else
>        #ifdef  _WINDOWS
>               #ifdef qpid_proton_EXPORTS
>                      #define QPID_PROTON_API __declspec(dllexport)
>                      #ifdef qpid_proton_python_EXPORTS
>                            #define QPID_PROTON_PY  __declspec(dllexport)
>                      #else
>                            #define QPID_PROTON_PY 
>                      #endif
>               #else
>                      #define QPID_PROTON_API __declspec(dllimport)
>                      #ifdef qpid_proton_python_IMPORTS
>                            #define QPID_PROTON_PY     __declspec(dllimport)
>                      #else
>                            #define QPID_PROTON_PY
>                      #endif
>               #endif
>        #else
>               #define QPID_PROTON_API
>        #endif
> #endif
> That means all the headers will need to be changed to include the macros.
> e.g.
> QPID_PROTON_API      pn_data_t *pn_data(size_t capacity);
> QPID_PROTON_API      void pn_data_free(pn_data_t *data);
> QPID_PROTON_PY       int pn_data_errno(pn_data_t *data);

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to