phosek added a comment. In https://reviews.llvm.org/D54724#1303809, @dim wrote:
> I think this is the wrong direction, placing "common" code in > `addCXXStdlibLinkDeps`, which then has all kinds of ugly ifs and switches for > different OSes? Let different OSes handle this in their own way, maybe. You mean handling this in individual `ToolChain` subclasses? I've considered doing that. The reason I went with a single method is because we already use this approach for other types of runtimes like sanitizers, XRay, etc. There'd be still some duplication for handling different C++ libraries, but I'd be fine changing the implementation to use that approach if there's a strong preference for doing so. > Until now I have not encountered an issue where I needed to add -lpthread to > the link command line for a static C++ application; I think that is only > needed when you actually use threading primitives? But still, I would rather > see this in the OS-dependent handling functions. Have you been using libc++ or just libstdc++? libstdc++ is cheating a bit, because it relies on threading functions that are provided by libgcc (which in turn call into pthread), so -lpthread is not needed when using libstdc++, even when you link it statically. libc++ doesn't rely on these functions because it supports different builtin libraries (like compiler-rt) hence having to specify -lpthread explicitly. Repository: rC Clang https://reviews.llvm.org/D54724 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
