Hello Waldemar, Ahhh, that was exactly what I needed! Thanks, must've completely overlooked this the whole time. Setting the kernel header destination to the same used for $INSTALL_HDR_PATH/include has uclibc building now! Mainly because I haven't built a cross-compiling toolchain with a proper sysroot yet. I have to familiarize myself with crosstool-ng for that, in fact I will need this for a few projects... But, for now, I have a nice and working setup on-device. In fact, it's running Jenkins, Home Assistant and TVHeadend just fine. So, if I can, I just throw a compile job in a screen. It's definitively the lazier approach, but one that works. :) That is... complicated. So, in the Debian Wiki, they tell you to use a certain set of repos, which are "based" off the Sid branch, but actually entail a rolling release that spans all the way into Trixie - past Bookworm. See: root@riscboi /n/o/uclibc-ng ((v1.0.45))# cat /etc/apt/sources.list # Original from image: #deb https://snapshot.debian.org/archive/debian-ports/20221225T084846Z unstable main # Suggested via wiki: # https://wiki.debian.org/RISC-V#Package_repository deb https://deb.debian.org/debian sid main contrib non-free non-free-firmware #deb https://deb.debian.org/debian unreleased main deb-src https://deb.debian.org/debian sid main The wiki article plus some digging led me here. And with a bit of u-boot configuration, I have a very stable system - even with a quite recent kernel. It is still very much a state of "it could break any time", since I actually don't exactly know what those repos are really based off of, and the os-release doesn't tell me much either. # cat /etc/os-release PRETTY_NAME="Debian GNU/Linux trixie/sid" NAME="Debian GNU/Linux" VERSION_CODENAME=trixie ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" But... it works - has even booted right back up after a blackout had hit my town just fine. I do want to pick up maintainership for armbian though, to get this into a more stable state. Curiosity for one; but I also want to bootstrap a build environment for Alpine's abuild. Since there are many Docker images that rely on alpine:3.19, I want to build those... myself. I can't reach anyone at Alpine to figure out what the exact reason is for not building a full distribution or at least a rootfs that can be used for Docker - so instead of waiting for answers and spinning in circles, I will just get my own hands dirty and see how far I can get - and then try again, this time with some results and work to showcase that I had put into this. One way to build such an environment is to use a small toolchain that is "as independent as possible". So, since uclibc leans very well into being statically compiled, and can work nciely with GCC, I thought it'd be a good idea to learn how to work with uclibc first before taking the next step into automating the builds through my Jenkins instance. The board has a 1TB NVMe SSD attached - so I have plenty of space and time to do my builds, grab the results, put them in a repo or other storage and them use that to build Docker images ... hopefuly. That, at least, is the long term goal. As a side-thing, it never hurts to know a little more about libc and the other sys internals. :) Hope that answers everything! Oh, and my build finished just now. Again, thanks for the pointer, that was exactly what I needed. Kind regards, Ingwie Waldemar Brodkorb <wbx(a)openadk.org> schrieb am Freitag, 1. März 2024 um 09:08: > Hi Kevin, > Kevin Ingwersen wrote, > > Hello there! > > > I am having a bit of a "moment" here, trying to build ucLibC on my VisionFive2. I have configured most of the things I would like the library to feature, but when I try to actually build it, it can not find my headers properly. > > > I have tried /usr, /usr/include and also used find to locate the folders that it was looking for, but to no avail. It is either linux/errno.h, asm/errno.h or asm/unistd.h that can not be found. > > > The kernel is self-built (since the upstream currently lacks two patches required for full SoC support) off the 6.6.0 branch and headers are installed to their standard location, including /usr/src/linux-headers-$(uname -r). > > > What is the expected structure to be found under .config's KERNEL_HEADERS? > And then put /home/wbx/linux/include as kernel header path.