[PATCH] D89339: [gn build] Attempt at statically linking against libc++ trunk

[Nico Weber via Phabricator via llvm-commits]

thakis added a comment.

Per chat, one issue was that you wanted a config to have deps. Configs can't have deps. The hack we use in Chromium for this is that we make executable() and shared_library() a custom template (here:  https://source.chromium.org/chromium/chromium/src/+/master:build/config/BUILDCONFIG.gn;l=466?q=buildconfig.gn&ss=chromium) and then make these base templates depend on libcxx (https://source.chromium.org/chromium/chromium/src/+/master:build/config/BUILD.gn;l=280?q=executable_deps&ss=chromium / https://source.chromium.org/chromium/chromium/src/+/master:build/config/BUILD.gn;l=257?q=executable_deps&ss=chromium). That's pretty heavy machinery, but it might be the best approach.

Another thing to consider: For building compiler-rt, we first build clang and then build compiler-rt with just-built clang. This is called (I think? might be wrong) the "runtimes build" in cmake and was considered to be the best way to build compiler-rt by several people at llvm conf 2019. IIRC there was some talk to use this model for libc++ too, but I don't remember if people thought that was a good idea, or if that's a thing. (ldionne will know, and maybe phosek). We don't current do that in the GN build, but if we were to do it, then this patch would introduce a dependency cycle: You'd need clang to build libc++, but now you also depend on libc++ for building clang since we want to statically link it.

One way out would be to build clang against system libstdc++ first (or: to build libc++ with the system compiler first), and then in a secondary toolchain and do the real build there. That'd add another full build of clang to the build progression (build clang, build bootstrap libc++ clang, build instrumented libc++ clang, collect profiles, build final libc++ clang using profile data (4 clang builds -- and if we wanted to use fcs-profile-generate we'd need another round for that). Maybe we could fold it into the bootstrap build or something. But the toolchain view (in the gn toolchain sense, not in the general sense) there's another approach: Toolchains _can_ have deps, per-toolchain args, and can add flags to all links and compiles, so another idea could be to add libc++ flags everywhere that way. (But there might be no way to _remove_ these flags, but maybe that's ok here?)

Maybe it comes down to if you want to get just this feature (clang + static libc++) or the whole clang+pgo+bootstrap pipeline. If the latter, it's probably worth thinking about if we want to do this in a single gn build with toolchains (appealing, but not completely clear how you'd run the profile collection step that way -- i gues the "collect profiles" step would run a script provided by a gn arg?) or if we'd want to keep the model that we're currently using in Chromium where we run the build a few times driven by a python script. (The cmake build also offers a way to do all steps in a single invocation, but we decided to go with the python driver since we felt writing build logic in python is easier to do than in cmake.) And if we do the multi-build-driven-from-outside approach, we wouldn't necessarily have to build libc++ from inside either -- a later build could take a gn arg pointing to a libc++ from an earlier build.

So, the goal isn't fully clear to me, and that makes it a bit difficult to think about what's a good design. Maybe we should have a small doc listing goals, non-goals, and tradeoffs and talk through that first :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89339/new/

https://reviews.llvm.org/D89339