[cfe-dev] [libc++] Guarantee that TUs built with different versions of libc++ can be linked together

[Duncan P. N. Exon Smith via cfe-dev]

I support this change too.

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).

> On Aug. 14, 2018, at 10:11, Reid Kleckner <rnk at google.com> wrote:
> 
> 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.
> 
> I think most people with standard library version skew typically only have skew between separate DSOs.
> 
> On Tue, Aug 14, 2018 at 6:49 AM Louis Dionne via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> Hi,
> 
> 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.
> 
> 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.
> 
> Does anybody have objections to this change?
> 
> Louis
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180814/31aa5855/attachment.html>