
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 14, 2018, at 13:56, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 14, 2018, at 1:19 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" class="">dexonsmith@apple.com</a>> wrote:</div><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I support this change too.<div class=""><br class=""></div><div class="">At least in the short term, I think vendors should still have the capability to provide this guarantee without user opt-in by changing the default macro settings (switching it to a user opt-out).<br class=""></div></div></div></blockquote><div class=""><br class=""></div>I agree with both of these points.</div></div></div></blockquote><div><br class=""></div><div>I implemented these in the latest revision of <a href="https://reviews.llvm.org/D50652" class="">https://reviews.llvm.org/D50652</a>.</div><div><br class=""></div><div>With <a href="https://reviews.llvm.org/D50652" class="">https://reviews.llvm.org/D50652</a>, by default, internal_linkage is NOT used and it is NOT safe to link TUs compiled with different versions of libc++. When _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE is defined, internal_linkage is used and it IS safe again to link TUs compiled with different versions of libc++.</div><div><br class=""></div><div>To make that the default behavior, libc++ can be configured with `cmake <…> -DLIBCXX_ABI_HIDDEN_USE_INTERNAL_LINKAGE=ON` and _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE will be defined by default.</div><div><br class=""></div><div>Bikeshedding on the name of that option is welcome on the review page — but I’d like to keep the form _LIBCPP_ABI_XXX to be consistent with other ABI-related macros.</div><div><br class=""></div><div>Louis</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug. 14, 2018, at 10:11, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I 100% support not providing this guarantee by default. It always seemed a bit too heroic to me for libc++ to try to provide this support.<div class=""><br class=""></div><div class="">I think most people with standard library version skew typically only have skew between separate DSOs.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Aug 14, 2018 at 6:49 AM Louis Dionne via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">

<br class="">

libc++ currently allows TUs that were built using different versions of libc++ to be linked together. Roughly speaking, this is achieved by making sure that anything not ABI-stable is local to each TU. This also allows distributing a static archive without caring too much about the version of libc++ it was compiled with, at least in principle. Supporting this use case creates code bloat for all users of libc++, since private functions are duplicated in each TU.<br class="">

<br class="">

I posit that few clients actually care about this, yet everybody is paying for it in terms of executable size. Hence, I would like to change the default guarantee offered by libc++ from "this use case is supported" to "this use case is not supported". The use case would still be supported by defining a macro for those that need it.<br class="">

<br class="">

Does anybody have objections to this change?<br class="">

<br class="">

Louis<br class="">

_______________________________________________<br class="">

cfe-dev mailing list<br class="">

<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">

<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">

</blockquote></div>

</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>