[libc-commits] [PATCH] D82404: [libc] Minimal Darwin support

Fri Jun 26 23:54:06 PDT 2020

sivachandra added a comment.

In D82404#2118254 <https://reviews.llvm.org/D82404#2118254>, @abrachet wrote:

> Would you mind looking if it is possible for a program not to be linked against `LibSystem.dylib` which contains Apple's libc? I thought it was the case that it wasn't possible, but I might be wrong.
>
> > It stills fails the liniting. It claims that stddef.h and stdint.h are system headers. stddef.h and stdint.h are provided by the libc and the resource directory of clang ...
>
> @PaulkaToast Might have some insight here, or maybe ideas on what we can do. But it does make sense that the clang function used in the linter is saying these are system headers, they are provided by Apple also. `/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stddef.h` This one isn't provided by `clang`, right?

On Darwin/BSD, I think the OS provides the libc. Not sure if `-ffreestanding` has any implications. So, for Darwin/BSD, we probably have to use a whitelist approach?

A more important question on Darwin/BSD is, what exactly does a libc mean? Since the OS provides the libc (including the headers), should we just implement redirectors for everything? May be not. May be LLVM-libc will be an alternate for users wanting to use it and so we should be like any normal library. There can still be questions like, for how much of the OS provided libc do we provide an alternate?

However we evolve for Darwin/BSD, I do not think we need to block on concrete answers to the above questions at this point in time. At the same time, my notes here are probably not helping this patch in anyway. I did see @tschuett pointing out other valid problems. Unfortunately, I will be away until 6th of July so I will not be picking this patch up until then. If others have any further thoughts/opinions, feel free to share.

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

https://reviews.llvm.org/D82404