<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 8, 2016 at 12:06 PM, Filipe Cabecinhas <span dir="ltr"><<a href="mailto:filcab+llvm.phabricator@gmail.com" target="_blank">filcab+llvm.phabricator@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It seems some people on this thread (I'm sorry if everyone is taking this into account, but it seemed to me that this was going unnoticed, I want to make sure everyone is on the same page) is only talking about linking (or not) the sanitizer runtimes. But that's not the only thing.<div><br></div><div>Depending on the OS, -fsanitize will also link in the sanitizer's dependencies, which might include libdl, libc++, and others.</div></blockquote><div><br></div><div>I think this is actually consistent across OSs: on non-Darwin, -nodefaultlibs turns off implicit linking of the sanitizer runtimes' dependencies. On Darwin, there are no additional dependencies (the sanitizer runtimes are linked as DSOs). Also, libc++ is not one of the dependencies that we implicitly link due to -fsanitize. (Those are -lpthread, -lrt, -lm, and sometimes -ldl.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>That was the reason why the patch was reverted last time we tried to change this flag's behavior: a sanitized libc++ needs the sanitizer libs, but not libc++... And it might need other dependencies for the sanitizers.</div><div><br></div><div>Maybe have something like:</div><div>-fsanitize=blah links all libs</div><div>-fsanitize=blah -nodefaultlibs links nothing</div><div>And then have two flags for explicitly linking either the sanitizer flag or the dependencies? Libc++ would still have the problem of wanting some dependencies but not all, though :-(</div></blockquote><div><br></div><div>If the goal is to make it easier to link standard library implementations, maybe instead we should add a -nodefaultlibs++, mirroring -nostdinc++, to only remove the C++ standard library parts from the link and leave all other implicit libs alone?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Thank you,</div><div><br></div><div> Filipe<span></span></div><div class="HOEnZb"><div class="h5"><div><br>On Thursday, 8 September 2016, Anna Zaks <<a href="mailto:zaks.anna@gmail.com" target="_blank">zaks.anna@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">zaks.anna added a comment.<br>
<br>
> I don't see the point of adding another flag to control this when we already have a perfectly good set of<br>
<br>
>  flags that already do the right thing -- that takes us three levels deep in flags overriding the behavior of<br>
<br>
>  other flags, and I don't see how it actually helps our users in any way.<br>
<br>
<br>
Going with silently linking the sanitizer runtimes when -nostdlib is passed will cause regressions in user experience. They will start getting inexplicable run time failures instead of build failures. Which solution do you propose to fix this problem?<br>
<br>
This specific situation comes up often on internal mailing lists, so we should not go for a solution that regresses the behavior on Darwin.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D24048" target="_blank">https://reviews.llvm.org/D2404<wbr>8</a><br>
<br>
<br>
<br>
</blockquote></div>
</div></div></blockquote></div><br></div></div>