On Aug 9, 2013, at 1:43 PM, Nico Rieck <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
