<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 22, 2015, at 8:38 PM, Marshall Clow <<a href="mailto:mclow.lists@gmail.com" class="">mclow.lists@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><span class="im">On Wed, Jul 22, 2015 at 1:55 AM, David Chisnall <span dir="ltr" class=""><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank" class="">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Marshall,<br class=""><br class="">For some background: We ship libc++ in both the base system and in ports. Some things use the version in ports, but we expect it to be a drop-in replacement (i.e. if something links libc++ and works with the one in base, then it must also work with the one in ports). Mostly the one in ports is used by things that require C++14 on systems that ship a libc++ that’s C++11-only.<br class=""></blockquote><div class=""><br class=""></div></span><div class="">OK - thanks for the background.</div><span class="im"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If we’re going to ship them in the FreeBSD base system at all, then we need to be able to guarantee ABI (and API) compatibility over the lifetime of a FreeBSD release (5 years). This means that we’d want to make sure, at the very least, they they’re in versioned namespaces and that people can opt in to newer ones if they want, but still have the older ones available.<br class=""></blockquote><div class=""><br class=""></div></span><div class="">Yeah, I can't do that for the TSes.</div><div class=""><br class=""></div><div class="">They're "experimental". That means that they can (and will) change - and the changes are not under my control. </div><div class=""><br class=""></div><div class="">I (and the others who work on libc++) try very hard to maintain ABI compatibility for the things in the standard; and I think we do a pretty good job. But it's a fair amount of work, and I don't want to take on the burden of doing that for stuff that the committee has declared as "not final".<br class=""></div><div class=""><br class=""></div><div class="">That's one of the reasons that I started this email thread - to figure out a good way to hand this.</div><div class=""><div id=":277" class="" tabindex="0"><img class="" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div><span class=""><font color="#888888" class=""><div style="font-size:12.8000001907349px" class=""><br class=""></div><div style="font-size:12.8000001907349px" class="">-- Marshall</div><div class=""><br class=""></div></font></span></div></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@cs.uiuc.edu" class="">cfe-dev@cs.uiuc.edu</a><br class="">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""><div class="">I just noticed this thread, so I apologize for being a little late.</div><div class=""><br class=""></div><div class="">On OS X, we can do something similar to how we are handling the Swift runtime:</div><div class=""><br class=""></div><div class="">- Build the TSes in a separate dylib, and distribute that dylib (with its headers) with the compiler.</div><div class=""><br class=""></div><div class="">- When building an app that uses a TS, embed the dylib for the TS inside the app bundle itself.</div><div class=""><br class=""></div><div class="">- The embedded dylib would need to be ABI compatible with the core libc++ dylib on the host system, but that’s as far as it would need to go. As the TSes evolve, the dylib would change and the app would need to get rebuilt anyway when it picks up a new compiler.</div><div class=""><br class=""></div><div class="">The major downside of this approach is that it creates an expectation of backwards deployment to earlier OSes, even if the TS makes it into the core libc++ dylib on the host system at a later stage.</div></body></html>