On Fri, Jul 20, 2012 at 2:17 PM, Дилян Палаузов <dilyan.palau...@aegee.org>wrote:
> Hello Michael, > > there is a point with dllexport/dllimport, however when not building for > Windows, the argumentation does not apply and the recommendation for use > LIBFOO_DLL_EXPORTED in the header files is suboptimal in my eyes. > Indeed, when you don't care about compatibility with MSVC, you don't need to put the decorators into the headers. OTOH if you care about compatibility with MSVC, then decorators are needed in the headers, at least for variables (including class static variables). > > Looking at the documentation of module lib-symbol-visibility, at the very > end, I might oversee something, but I have the feeling, that when > ./configure determined support for -fvisibility=hidden, and > BUILDING_LIBFOO, HAVE_VISIBILITY and _MSC_VER are all defined, from > > #if BUILDING_LIBFOO && HAVE_VISIBILITY > #define LIBFOO_DLL_EXPORTED __attribute__((__visibility__(** > "default"))) > #elif BUILDING_LIBFOO && defined _MSC_VER > #define LIBFOO_DLL_EXPORTED __declspec(dllexport) > #elif defined _MSC_VER > #define LIBFOO_DLL_EXPORTED __declspec(dllimport) > #else > #define LIBFOO_DLL_EXPORTED > #endif > > follows, that LIBFOO_DLL_EXPORTED is > __attribute__((__visibility__(**"default"))) > whereas it shall be > declspec(dllexport) > as declspec(dllexport) implies visibility(default), and > visibility(default) does not help to DLL-export the symbols. > The problem is not at export time, it's at import time, for client code using the headers. A DLL-exported variable that is not decorated with dllimport (from the client code point of view) will result in undefined reference at link stage. By decorating variables (and more generally functions) in the headers, you can achieve MSVC compatibility with little efforts, with the CPP snippet above. But again, this only applies when you care about compatibility. Michael.
