In D100968#2705598, @MaskRay wrote:

On newer Linux distributions

Different distributions have different strategies migrating the /usr/bin/python symlink. Debian and its derivatives provide python-is-python2 and python-is-python3. If neither is installed, the user gets no /usr/bin/python.

LG with this clarified.

Minor nit, looks good otherwise. (:
If you haven't run git clang-format HEAD~1 before you land the patch.

After comments are addressed LGTM but you might want to wait for approval from sivachandra.

In D81737#2089966, @mehdi_amini wrote:

I don't know where is the best place for the Docker config to live, but there are some in the monorepo already FYI:

llvm-project/libcxx/utils/docker/debian9/buildbot/Dockerfile
llvm-project/clang/tools/clang-fuzzer/Dockerfile
llvm-project/libc/utils/buildbot/Dockerfile
llvm-project/llvm/utils/docker/debian8/Dockerfile
llvm-project/llvm/utils/docker/example/Dockerfile
llvm-project/llvm/utils/docker/nvidia-cuda/Dockerfile

In D80495#2061127, @abrachet wrote:

FWIW, we should do something about clang and clang-tools-extra being required. It also causes the Harbormaster builds to fail because it not longer builds all top level targets anymore.

In D79192#2048306, @sivachandra wrote:

In D79192#2048277, @PaulkaToast wrote:

As for the Linux dev headers I think instead of a work around using clang-tidy, it might just be better to remove our dependency on the dev headers all together, especially since the dev headers differ between platforms such as sigset_t on AARCH64 vs x86.
I can send out a separate patch out for this as well.

What do you mean remove the dependency on dev headers? Does it mean that we make copies of linux definitions in LLVM libc tree?

Sorry for the delayed response!

In D80178#2043168, @sivachandra wrote:

Doesn't this trigger a "defining builtin macro" warning/error?
Does adding -ffreestanding to the compile step of the raw object file fix the problem you are seeing and also avoid tampering with __STDC_HOSTED__ macro?

Gotcha thanks!

Abandoned in favor of D79192.

In D79192#2015295, @sivachandra wrote:

• Instead of creating a target for every entrypoint, have you considered generating a single file which:
  1. Includes all header files listed in the api.td.
  2. Lists cpp:Function pointers to all functions as required by api.td.

There definitely are problems that need to be solved with this approach. For example, how do you ensure all public header files are already present in the build/.../libc/include directory. But, the appeal of this approach is that one does not have to create explicit or implicit targets for "integration tests". There would be just one target which would test everything in one go.