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.
You are correct. It was my error in my explanation here of the situation. I did correctly point out to the clang developers that compiling with gcc/mingw using __attribute__((__dllexport__)) does compile the example I gave without errors, that compiling with VC++ using __declspec(dllexport) does compile the example I gave without errors, but that clang fails to do so using either.
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.
Thanks for the explanation. So we really have no way to solve this from within Boost.
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.
Actually clang only aims for compatibility with MSVC in their clang for Windows version which targets VC++. In their clang for Windows implementation which targets mingw/gcc they do aim for a certain amount of compatibility with mingw/gcc. I am using the version of clang on Windows targeting mingw/gcc. The version on Windows which targets VC++, which I have been able to build, I never use because 1) it replicates some of the VC++ preprocessor bugs breaking Boost PP and 2) It is not supported directly in Boost Build ( although I can workaround that problem ).
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.
I agree with that but so far nobody at clang has continued the discussion after an initial flurry of responses. Thanks for the clarification and I apologize for the confusion reporting the issue here.