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.
Depending on the OS, -fsanitize will also link in the sanitizer's dependencies, which might include libdl, libc++, and others. 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. Maybe have something like: -fsanitize=blah links all libs -fsanitize=blah -nodefaultlibs links nothing 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 :-( Thank you, Filipe On Thursday, 8 September 2016, Anna Zaks <zaks.a...@gmail.com> wrote: > zaks.anna added a comment. > > > I don't see the point of adding another flag to control this when we > already have a perfectly good set of > > > flags that already do the right thing -- that takes us three levels > deep in flags overriding the behavior of > > > other flags, and I don't see how it actually helps our users in any way. > > > 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? > > This specific situation comes up often on internal mailing lists, so we > should not go for a solution that regresses the behavior on Darwin. > > > https://reviews.llvm.org/D24048 > > > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
