<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><blockquote type="cite" class=""><div class="">On Jul 19, 2018, at 19:51, Dean Michael Berris <<a href="mailto:dean.berris@gmail.com" class="">dean.berris@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">On 20 Jul 2018, at 01:49, James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""><br class=""><br class="">I haven't looked at what libfuzzer does, but as you've described it, I'd say this _doesn't_ seem a reasonable use-case. If you want to link libc++ (or any other library!) hidden inside your library, you should be using a version-script to only expose symbols that you intend to expose.<br class=""><br class=""></blockquote><br class="">In XRay, we go out of our way to not use any standard-library defined symbols that need linkage. We have a tests which ensure that we are able to link the XRay runtime without the standard library dependency. This has been discussed before, I think, precisely in this context.<br class=""><br class="">The options for libFuzzer might be more limited since it’s a special use-case, and I’m sure unless the fuzzer runtime removes dependencies on standard library symbols that libc++ shouldn’t be prioritising this use-case. Another way of saying this is that the cost of ensuring that libFuzzer continues to work despite changes to libc++ should be borne by libFuzzer, not the other way around.<br class=""></div></div></blockquote><div><br class=""></div><div>Well, that’s also my impression, but I don’t know how we can actually change this given there are clients using it and the status quo usually wins when no consensus can be reached. What I suggest is that we instead start implementing my proposal at <a href="http://lists.llvm.org/pipermail/cfe-dev/2018-July/058457.html" class="">http://lists.llvm.org/pipermail/cfe-dev/2018-July/058457.html</a> (I’m waiting for reviews on <a href="https://reviews.llvm.org/D49240" class="">https://reviews.llvm.org/D49240</a> BTW), which will solve most concrete problems we have right now. In the not too distant future, we can then evaluate the feasibility of removing support for interoperability of TUs built with different versions and the benefits of doing so — as a separate effort (which I’d be glad to volunteer for).</div><div><br class=""></div><div>My primary concern at this point is about moving forward and solving the concrete problems we have with the use of __always_inline__, and I’m willing to compromise to get there, and to do it in stages if I have to.</div><div><br class=""></div><div>Cheers,</div><div>Louis</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I don’t know how much work is required to use a work-around as James describes with symbol visibility or “privatising” the symbols libFuzzer uses from libc++. It could be less than trying to remove the dependency on libc++ instead.<br class=""><br class="">-- Dean<br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>