On 2/14/2015 4:52 PM, Andrey Semashev wrote:
On Saturday 14 February 2015 14:38:35 Edward Diener wrote:
Do we want to change BOOST_SYMBOL_EXPORT on clang with Windows targeting mingw/gcc to specify __attribute__((__visibility__("default"))) as we do with mingw/gcc ?
First, on Windows for gcc/mingw __attribute__((__dllexport__)) is used, not visibility.
The way I understand it, __declspec(dllexport) (or the similar attribute) is not equivalent to __attribute__((__visibility__("default"))), even if the latter does have a sensible meaning on Windows. Exported symbols are mangled differently, and on the import side shims are generated for the imported functions (not sure if there are other consequences for classes and data, but there probably are, at least to support delayed library loading). Visibility attribute does not affect mangling nor generates anything but simply marks the symbol for the linker to be externally visible or not. This makes no sense on Windows since its linker only works with exported symbols. Note that by default all symbols are visible but certainly not exported.
I suspect, if you make BOOST_SYMBOL_EXPORT to be __attribute__((__visibility__("default"))), you won't be able to link with those symbols from other libraries/applications compiled with clang or other compilers. And there is also GetProcAddress() to consider.
My position on this issue is that as long as clang team aims for compatibility with MSVC, they should make clang work similarly to MSVC. If MSVC compiles that code, then it probably doesn't generate (nor export) these functions if they can't be generated. Such behavior would seem sensible to me because otherwise there would be no way to export non-copyable classes. IMHO, clang should follow.
After more comments on the clang developer's mailing list I have reported this bug to clang at http://llvm.org/bugs/show_bug.cgi?id=22591 after being asked to do so on the developer's mailing list.