On Fri, Mar 11, 2016 at 7:32 AM, Nico Weber <tha...@chromium.org> wrote:
> I reverted this in 263246 for now. I think the right fix is just to > add _LIBCPP_INLINE_VISIBILITY to the new constructor, but I'm not 100% sure. > > On Thu, Mar 10, 2016 at 10:21 AM, Nico Weber <tha...@chromium.org> wrote: > >> I think this is ABI-breaking. On OS X, new libc++ headers must work with >> old system libc++.dylibs. When I build in this setup with this change, I get >> >> Undefined symbols for architecture x86_64: >> "std::__1::basic_string<char, std::__1::char_traits<char>, >> std::__1::allocator<char> >::basic_string(std::__1::basic_string<char, >> std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned >> long, std::__1::allocator<char> const&)", referenced from: >> >> The new function probably needs that always_inline treatment that many >> other functions have? >> > Thanks I'll re-submit with the inline stuff after this week. -- Marshall
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
