<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 Feb 1, 2021, at 16:03, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" class="">ken.cunningham.webuse@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On MacPorts we are just getting into this issue, in our case trying to build a new libc++.dylib that will be accepted by the existing system frameworks on 10.7 to 10.13 to support c++17 software on older systems without resorting to libstdc++ from gcc.<div class=""><br class=""></div><div class=""><div class="">Is this macro of value in helping avoid ODR violations?  I’m just investigating that now:</div><div class=""><br class=""></div><div class=""><span style="font-family: Verdana, Arial, "Bitstream Vera Sans", Helvetica, sans-serif; font-size: 13px; background-color: rgb(238, 238, 238);" class=""> _LIBCPP_HIDE_FROM_ABI_PER_TU</span></div><div class=""><font face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif" size="2" class=""><span style="background-color: rgb(238, 238, 238);" class=""><br class=""></span></font></div></div></div></div></blockquote><div><br class=""></div><div>Pasting from the documentation:</div><div><br class=""></div><div><div>**_LIBCPP_HIDE_FROM_ABI_PER_TU**</div><div>  This macro controls whether symbols hidden from the ABI with `_LIBCPP_HIDE_FROM_ABI`</div><div>  are local to each translation unit in addition to being local to each final</div><div>  linked image. This macro is defined to either 0 or 1. When it is defined to</div><div>  1, translation units compiled with different versions of libc++ can be linked</div><div>  together, since all non ABI-facing functions are local to each translation unit.</div><div>  This allows static archives built with different versions of libc++ to be linked</div><div>  together. This also means that functions marked with `_LIBCPP_HIDE_FROM_ABI`</div><div>  are not guaranteed to have the same address across translation unit boundaries.</div><div><br class=""></div><div>  When the macro is defined to 0, there is no guarantee that translation units</div><div>  compiled with different versions of libc++ can interoperate. However, this</div><div>  leads to code size improvements, since non ABI-facing functions can be</div><div>  deduplicated across translation unit boundaries.</div><div><br class=""></div><div>  This macro can be defined by users to control the behavior they want from</div><div>  libc++. The default value of this macro (0 or 1) is controlled by whether</div><div>  `_LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT` is defined, which is intended to</div><div>  be used by vendors only (see below).</div><div><br class=""></div><div>Basically, this macro allows mixing different TUs or static archives built with different versions of libc++. That is relevant if you have multiple versions of libc++ within the same executable, which doesn't appear to be your case here.</div><div><br class=""></div><div>Louis</div></div><div><br class=""></div><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=""><font face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif" size="2" class=""><span style="background-color: rgb(238, 238, 238);" class="">Ken</span></font></div><div class=""><font face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif" size="2" class=""><span style="background-color: rgb(238, 238, 238);" class=""><br class=""></span></font></div><div class=""><font face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif" size="2" class=""><span style="background-color: rgb(238, 238, 238);" class=""><br class=""></span></font><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Feb 1, 2021, at 12:19 PM, Louis Dionne via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div class="">On Feb 1, 2021, at 15:16, Louis Dionne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">On Feb 1, 2021, at 02:37, Tobias Hieta via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a>> wrote:<br class=""><br class="">Hello,<br class=""><br class="">We are working on an application where we want to have full support<br class="">for C++17 but still ship on older versions of macOS (10.9/10.10 in<br class="">this case). Our plan was to build our own libc++ from llvm and ship it<br class="">with the application and then pass "-D_LIBCPP_DISABLE_AVAILABILITY"<br class=""><br class="">This seemed to work fine in internal testing - but then we ran into a<br class="">similar issue as the one described here:<br class=""><a href="https://reviews.llvm.org/D74489#2497044" class="">https://reviews.llvm.org/D74489#2497044</a><br class=""><br class="">Now I can patch my copy of libc++ with the upstream fix for this - but<br class="">the comment below made me think otherwise:<br class=""><a href="https://reviews.llvm.org/D74489#2505156" class="">https://reviews.llvm.org/D74489#2505156</a><br class=""><br class="">We have run into problem where if you ship your own libc++ the system<br class="">frameworks loads the system libc++ and some strange errors happen - we<br class="">thought we could work around these issues - but maybe this is just us<br class="">being naive.<br class=""><br class="">So I guess my question is - is it possible to ship a custom libc++ in<br class="">a .app archive for older versions of macOS in order to use C++17? Or<br class="">is my only hope to raise the minimum version of our app and always<br class="">link to the system libc++?<br class=""></blockquote><br class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">Generally, I would say this is a tricky thing to do. As you mention, the problem is that if you link against any other library that does link against the system-provided libc++.dylib, you'll have ODR violations because some symbols will be found in both libraries. As a result, I believe you could also end up in a situation where you end up using globals from one library when the globals from the other library has been initialized. So basically, nothing good happens.</span><br class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">If you can ensure that your application doesn't pull in the system libc++.dylib (even transitively), then this would in theory be safe to do. Due to the brittleness of the solution, my immediate reaction would be to not recommend that. The reason why some parts of C++17 aren't available on older platforms is that we put the vtables required for exception classes in the dylib. That is a code size optimization that we think is worth the trouble. You can generally use the parts of C++17 APIs that can't throw exceptions even on older platforms because they don't require those vtable symbols - perhaps that is something you can consider?</span><br class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"></div></blockquote></div><br class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Also, Chrome is known to do something similar to what you're inquiring about. They build libc++ statically with hidden visibility, and then they link it into their application. I assume they also make sure to not export any symbol from libc++ that would be created by using the libc++ headers (e.g. by instantiating some function template). I don't know their setup very well, but I assume they make sure to not link against any other system library that does require libc++.dylib from the system, or else things get trickier as I explained above. But as long as you satisfy that requirements, I believe things have worked fairly well for them so far. You just have to be able and willing to walk that fine line.</div><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Louis</div><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class=""></div><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">libcxx-dev mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="mailto:libcxx-dev@lists.llvm.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">libcxx-dev@lists.llvm.org</a><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></body></html>