<div dir="ltr">Hi David,<div><br></div><div>Thanks for taking the time to respond.</div><div><br></div><div>> <span style="font-size:12.8px">If you can not modify the linkage of libstdc++ on your target platform, then the best solution is to use libstdc++ itself as the ABI library.</span></div><div class="" style="font-size:12.8px"></div><div class="" style="font-size:12.8px"><br></div><div class="" style="font-size:12.8px">Obviously I have no power to modify the linkage of libstdc++ in general. However I don't think using libstdc++ as the ABI library is the best default for libc++.</div><div class="" style="font-size:12.8px">I understand it is needed in order to support inter-operability but for obvious reasons I think libc++abi is the correct default to use out of the box.</div><div class="" style="font-size:12.8px"><br></div><div class="" style="font-size:12.8px">However the idea of using a linker script as libc++.so will also fix the case where libstdc++.so is actually used.</div><div class="" style="font-size:12.8px">When the user builds against libstdc++ the linker script will contain "INPUT(libc++.so.1 -lstdc++)".</div><div class="" style="font-size:12.8px"><br></div><div class="" style="font-size:12.8px">/Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 13, 2015 at 3:43 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Saleem,</div><div><br></div><div>Thanks for the response.</div><span class=""><div><br></div>> <span style="font-size:12.8px">Statically linking the ABI into the c++ library would ensure that the same ABI is always used, it would be unique across the process still, and would not impede using alternative ABI providers.</span><div><br></div></span><div>I was originally under the impression that this would prevent multiple libc++ versions from existing in the same executable because they would each contain a different copy of the libc++abi symbols.</div><div>Am I incorrect in this assertion?</div><div><br></div><div>I also don't see how using a linker script would impede using alternative ABI providers. The script could be tailored to support any of them. </div><span class=""><div><br></div><div>> <span style="font-size:12.8px"> </span><span style="font-size:12.8px">The other "downside" is that you cannot update the ABI provider without rebuilding all of libc++. </span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">However, this is a feature as well: you are certain that the ABI provider doesn't change (yes, libc++abi is pretty stable, but hypothetically, we may fix UB -- like the one with alignment of allocations done in libc++abi).</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">This is a major downside for libc++abi developers if we make this the default behavior. I also don't think people expect perfect ABI stability when building a ToT release of libc++. I agree with both your points but I don't think they are reasons to use this configuration as the default configuration. </span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>/Eric</div><div><span style="font-size:12.8px"><br></span></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 12, 2015 at 5:19 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 12 Oct 2015, at 00:58, Eric Fiselier via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> This approach is how FreeBSD ships their systems libc++. OS X take a<br>
> slightly different approach which uses also uses a shared ABI library.<br>
> It works by re-exporting libc++abi's symbols into libc++.dylib at<br>
> build time using the "-reexported_symbols_list" linker flag.<br>
<br>
</span>This is how FreeBSD ships libc++ (except that we use libcxxrt, not libc++abi), but it will cause problems on Linux unless you *also* change the way that libstdc++ is shipped.<br>
<br>
Libstdc++ statically links libsupc++ (the GNU equivalent of libcxxrt / libc++abi) and this has an impact on symbol versioning.  If something links to both libstdc++ with libsupc++ and libc++ with libc++abi then the ABI symbols will be distinct.  Throwing an exception in code using one and catching it in the other will break in difficult-to-diagnose ways.<br>
<br>
We addressed this by linking libstdc++ as a filter library against libsupc++ then against libcxxrt.  Libraries linking libstdc++ see the ABI symbols as having come from libstdc++, when in reality they are provided by libcxxrt.  This allows interoperability.<br>
<br>
If you can not modify the linkage of libstdc++ on your target platform, then the best solution is to use libstdc++ itself as the ABI library.<br>
<span><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>