phosek added a comment. What about other compiler-rt runtimes? Shouldn't we use the same approach for those?
In case of multiarch runtime layout, we already add <https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChain.cpp#L82> the runtime directory to the new `LibraryPaths` list, which is added <https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChain.cpp#L771> to the list of library paths. We could consider doing the same for the default layout, in which case all `getCompilerRT` would need to return is the name of the library rather than a path, but we would need to use `-l` for all compiler-rt runtimes, not just builtins. That's going to require more changes, but I think it's going to result in a cleaner design. @beanz would that work for Darwin as well? ================ Comment at: lib/Driver/ToolChains/CommonArgs.cpp:1164 + case ToolChain::RLT_CompilerRT: { + StringRef Path = TC.getCompilerRTArgString(Args, "builtins"); + StringRef Dir = llvm::sys::path::parent_path(Path); ---------------- Rather than parsing the return string below, wouldn't it be cleaner to modify `ToolChain::getCompilerRT` to return a tuple (`ToolChain::getCompilerRTArgString` could still return a string) and then use if here? ================ Comment at: lib/Driver/ToolChains/CommonArgs.cpp:1168 + if (Filename.consume_front("lib") && Filename.consume_back(".a")) { + CmdArgs.push_back(Args.MakeArgString("-L" + Dir)); + CmdArgs.push_back(Args.MakeArgString("-l" + Filename)); ---------------- When the multiarch runtime layout is being used, this will result in this path being added twice, once in the `ToolChain` constructor and once here. Repository: rC Clang https://reviews.llvm.org/D51440 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits