Or perhaps a `--target` flag that says "I'm targeting the linux kernel, not userspace, libcall these symbols (existing kernel functionality) rather than those (glibc interfaces)."

That won't solve it. Fil-C's memory safety relies on the Fil-C runtime

Just as the sanitizers have a runtime, the linux kernel has a re-implementation of those runtimes (the linux kernel does not link libgcc/compiler_rt) and IIRC the compiler will work differently (I forget which flags control that). Prior art here.

The sanitizer runtime is not nearly as complex as the Fil-C runtime.

Sanitizers don't have to deal with:

- https://fil-c.org/fugc

- https://fil-c.org/safepoints

Oh and it's not clear if the current revision of the capability model would work with memory mapped IO: https://fil-c.org/invisicaps

Does fil-c have a way of disabling the capability model for regions of code? (Rust's `unsafe` blocks come to mind).

Maybe if I ask enough stupid questions, you'll get pissed and get the kernel to build/work with fil-c just to prove a stranger on the internet wrong. :P

> Does fil-c have a way of disabling the capability model for regions of code? (Rust's `unsafe` blocks come to mind).

Nope

> Maybe if I ask enough stupid questions, you'll get pissed and get the kernel to build/work with fil-c just to prove a stranger on the internet wrong. :P

I love this attitude! :-)

> The kernel is compiled with Yolo-C. So that you can compile the kernel, a copy of GCC is installed in /yolo/bin/gcc.

Fil, you can compile the Linux kernel will clang+lld. `make LLVM=1` https://docs.kernel.org/kbuild/llvm.html

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).

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.

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.

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

>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!!

And so so full of stereotypes...

I feel attacked.

Where my Gundam Wing fans at? (there are literally dozens of us...dozens!)

Dunno, just upgraded Fedora to Fedora 43 and all of the games I had set up (wine) stopped working. Will try gaming on Linux again next decade.

You should rebuild the Wine environments. Or just use Steam.

Is this common with wine; that you need to rebuild your environments when upgrading??

There is nothing stopping the industry from standardising on an alternative form of expressing consent, for example on browser installation. GDPR is agnostic to the form the consent takes, as long as it's informed and freely given.

However, by far the biggest browser is funded by a corporation that wants tracking data across the web. I'm not very surprised that the corporation haven't made it easy to refuse just once.

Thanks Google.

Their libc is kind of a mess of various sources. I wonder what's going on there?

https://github.com/coredevices/PebbleOS/tree/main/src/libc

This is a false dichotomy, from someone who profits from such manufactured fear.

If folks are interested in compilers and looking for where to get started, we're always looking for new contributors:

Building the Linux kernel with LLVM: https://github.com/ClangBuiltLinux/linux/issues

LLVM itself: https://github.com/llvm/llvm-project/issues?q=is%3Aissue%20s...

> This works for Android because a good chunk of the tree is probably dead code for a single build (device drivers and whatnot)

Device drivers would exist in kernel sources, not the AOSP tree.