[PATCH] [libcxx] Visibility fixes for Windows

[Howard Hinnant]

On Aug 9, 2013, at 1:43 PM, Nico Rieck <nico.rieck at gmail.com> wrote:

> On 08.08.2013 23:02, Howard Hinnant wrote:
>> Thanks for your work on this.  If I understand correctly, types that exist only in the headers are decorated with _LIBCPP_TYPE_VIS_ONLY, and types that are compiled into the dylib are decorated with _LIBCPP_TYPE_VIS.
> 
> Correct, and I agree with extending this to inline-visibility types. Thanks for checking this!
> 
> A few issues are left:
> 
>> --------------
>> 
>> <regex>
>> 
>> class _LIBCPP_TYPE_VIS __match_any_but_newline
>> 
>> Should have no visibility tag because it is an inlined implementation detail.
>> 
>> --------------
> 
> But the char and wchar_t specializations of __match_any_but_newline<T>::__exec are compiled into the dylib in regex.cpp, which results in unresolved symbols for DLLs (even with them being virtual). I've opted to just decorate the specializations and added:
> 
> template <> _LIBCPP_FUNC_VIS
>    void __match_any_but_newline<char>::__exec(__state&) const;
> template <> _LIBCPP_FUNC_VIS
>    void __match_any_but_newline<wchar_t>::__exec(__state&) const;
> 
> 
> Second issue: I forgot that operator new/new[]/delete/delete[] must not be imported (or else it's impossible to replace them when using a Windows DLL) but they still have to be exported when building libc++. A proper Windows linker can match non-imported symbols to exported symbols if nothing better is available.
> 
> Third issue: valarray<size_t> is used as a member before the three extern template specializations are declared, which results in unresolved symbols. So I moved them further up.
> 
> I've attached a patch for my changes based on your last one, and also new full patch if needed.
> 
> -Nico
> <credits.patch><full.patch><incr.patch>

Thanks, Committed revision 188192.


Howard