<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 22, 2018 at 3:02 PM Louis Dionne <<a href="mailto:ldionne@apple.com">ldionne@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div>The problem here is that there's no function in the dylib that we can call that would itself have access to __vector_base_common<true>::__vector_base_common(), which has hidden visibility.</div><div><br></div><div>Also, even disregarding this issue, it turns out that preventing inlining of all methods that are part of the ABI is kind of a big deal -- I'm quite concerned about the performance impact this could have. I’d much rather pursue a path that does not require telling the compiler whether to inline something or not, as this is an orthogonal decision IMO. Does that make sense?</div></div></div></div></blockquote><div><br></div><div>True, if the dylib does not provide the symbols that are being called directly from user code, then neither of my suggestions will help. You really do need to emit the functions with linkonce_odr linkage, because they are not actually available, and the extern template declaration is a bit of a lie.</div><div><br></div><div>At this point, you might want to consider finding a way to make libc++.dylib expose the symbols so that at some point in the future so that these functions can be emitted as avaiable_externally instead of linkonce_odr.</div></div></div>