Gotcha. I am using gcc for building yolo-glibc, and the version I'm building (2.40) requires gcc.

So if I used clang, then I'd have three compilers (yolo-clang, gcc, fil-clang) instead of two (gcc, fil-clang).

Does fil-clang have `-fno-` flag to control disabling fil-c stuff?

Does the fil-c runtime depend on specifics from glibc, or is it that LFS doesn't support building with musl?

> We need to retain the Yolo GCC for compiling the Linux kernel.

Probably can replace that with s/the Linux kernel/glibc/. glibc maintainers have started upstreaming patches for building glibc with clang, but not sure yet what's the latest on that (large) patch series.

>Does fil-clang have `-fno-` flag to control disabling fil-c stuff?

No. I could add a flag like that, but that would make my patch to clang larger, which would make rebasing to new clang versions harder.

So I'm choosing not to add such a flag. For now.

> Do you depend on glibc, or is it that LFS doesn't support building with musl?

I support both glibc and musl.

LFS is glibc-based.

If you do get around to adding the flag, consider a suggestion for the color of bikeshed: `-fyolo`. (Can't find my April Fool's clang patch for adding `-feverything`; hard to search the phab archive)

Love it!!

All of the patches have been committed and the next release is a few weeks away.

Is there a reason not to use a clang-compilable kernel?

I do like the idea of shrinking the unsafe bit to just the fil-c runtime. Which maybe could be compiled with things like -fbounds-safety. And/or written in a memory-safe subset or variant of C.