sivachandra added a comment. In D97736#2605432 <https://reviews.llvm.org/D97736#2605432>, @echristo wrote:
> In addition to the bikeshed below, I'm not a huge fan of this in general. I > think we should assume that the libc we link is complete and thus it would > just be named "libc.<ext>" and in a sysroot somewhere. Another option is > perhaps looking at the rtlib option, but I'd want to see a bit of a writeup > there so we can see what we'd be doing. By not giving it a `libc.<ext>` name, we are actually implying that, "it is not the full libc that you expect." It is expected that it will be used along with another full libc. When LLVM libc is complete enough, then yes we should be giving it the conventional name of `libc.<ext>` and the experimental option can be thrown out. In D97736#2605159 <https://reviews.llvm.org/D97736#2605159>, @MaskRay wrote: > If the end goal is to provide a complete libc, and currently the usage is > expected to shadow system libc (this has to be very careful, as I don't know > how shadowing some important components like pthread shall work), perhaps the > name should convey this point? Yes. So, we have not done it yet, but the plan is to be able to build LLVM in two different modes: 1. The default mode: This mode only builds and packages the ABI independent and ABI agnostic parts of LLVM libc. The binaries produced from this mode are to be used with the `-experimental-llvm-libc`. The plan is also to make default mode work under `LLVM_RUNTIMES_BUILD`. 2. The full libc mode: In this mode, LLVM libc will be built as if it is a full libc. A special CMake option needs to be set to build in this mode. The binaries produced in this mode will include everything, including ABI sensitive pieces. They will be tested on bots but will not be practically useful for many months as we are still building out the libc. ================ Comment at: clang/include/clang/Driver/Options.td:3626 def specs : Separate<["-", "--"], "specs">, Flags<[Unsupported]>; +def experimental_link_llvmlibc : Flag<["-"], "experimental-link-llvmlibc">; def static_libgcc : Flag<["-"], "static-libgcc">; ---------------- echristo wrote: > Bikeshedding: Not a huge fan of this name. I'd rather a more general option > if we feel the need to select libc from an option rather than a sysroot. The idea is not to provide an option to "choose" a libc. The idea is that this option will help one use what LLVM libc provides while getting the rest from the system libc. I would think that the option to "choose" a libc is not related to this as LLVM libc is not complete. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97736/new/ https://reviews.llvm.org/D97736 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
