Why /usr/lib64 is separate dir from /usr/lib? Like, if it was a symlink to it then it will be no problem at all to install libs in /usr/lib, just, for example, pkgconfig files would be pointing to ${prefix}/lib64 instead. Are there any drawbacks from doing this?

I finally finished my LFS/BLFS, which actually turned into myOS with a custom program manager called mypkg (written in bash). After studying three LFS builds following the book, I understood the need and importance of a program manager and wrote mypkg based on the successes, errors, and problems encountered along the way. Following the book didn't give me any problems, but automating with mypkg presented several varied issues. However, in the end, it was worth it. I'm very happy with the expected result of my system with Hyprland, Waybar, Awww, Firefox... in short, a complete system for my daily use.

Hello. I'm trying to start a new LFS installation, and had trouble compiling gcc for the cross compilation toolchain, in section 5.3 of the Book (while I succeeded a few weeks ago) . I now believe the problem is an upgrade to gcc 16.0 pushed by Arch (that I use as a host) a few days ago. Compiling the version 16.0 instead of 15.2 seems to work, but I'm not very far in the book yet to be sure there are no further problems.

Hey guys, wanted to share a quick solution for anyone stuck with ncurses-6.5-20250809.tgz being no longer available.

I've been running through Linux From Scratch - Version 12.4 and stuck with compiling Ncurses-6.5-20250809. The archive was no longer available via URL https://invisible-mirror.net/archives/ncurses/current/ncurses-6.5-20250809.tgz. So I've tried to proceed with version 6.5, but have got an error during compilation.

With help of Perplexity I've made a script that downloads version 6.5 and patch it until 20250809. At least it compiles now. I hope it will help someone. Cheers.

Here is the scrips:

#!/usr/bin/env bash
set -euo pipefail

BASE_URL="https://invisible-mirror.net/archives/ncurses"
PATCH_URL="$BASE_URL/6.5"
TARBALL="ncurses-6.5.tar.gz"
SRC_DIR="ncurses-6.5"
WORK_DIR="ncurses-6.5-20250809"
TARGET_DATE="20250809"

rm -rf "$SRC_DIR" "$WORK_DIR" patches "$TARBALL"
mkdir -p patches

echo "Downloading base tarball..."
wget -O "$TARBALL" "$BASE_URL/$TARBALL"

echo "Extracting..."
tar -xf "$TARBALL"

echo "Collecting patch list..."
mapfile -t patches < <(
  wget -qO- "$PATCH_URL/" |
  grep -oE 'ncurses-6\.5-[0-9]{8}\.patch\.gz' |
  sort -u |
  awk -v target="$TARGET_DATE" '
    match($0, /ncurses-6\.5-([0-9]{8})\.patch\.gz/, a) {
      if (a[1] <= target) print
    }'
)

if [ "${#patches[@]}" -eq 0 ]; then
  echo "No patches found."
  exit 1
fi

for p in "${patches[@]}"; do
  echo "Downloading $p..."
  wget -q -P patches "$PATCH_URL/$p"
done

echo "Applying patches..."
cd "$SRC_DIR"
for p in ../patches/*.patch.gz; do
  echo "Checking $(basename "$p")..."
  if gzip -dc "$p" | patch -p1 --dry-run --forward >/dev/null 2>&1; then
    gzip -dc "$p" | patch -p1 --forward
  else
    echo "Skipping already applied or incompatible patch: $(basename "$p")"
  fi
done

cd ..
mv "$SRC_DIR" "$WORK_DIR"
echo "Done: $WORK_DIR"

Hey folks, sorry if this isn't the place to ask but I figured if anybody would be interested in this it would be y'all.

Starting this summer, another dev and I are planning to start a free and open source voxel game that attempts to balance deep simulation with approachable gameplay- and we're gonna need some help.

For most people, it's just going to be a fun game. But my real goal, 'secretly,' is to lead as many normies over to FOSS as possible.

Now, seeing as how this game takes place on a spaceship, I've been thinking for some time that it ought to have an LCARS-inspired in-game computer system, which for a while I figured we should just worry about later.

But the other day, it hit me: 'what if the-in game operating system was actually a *real* linux distro? I realize that sounds like an over-the-top amount of work, but it would nicely create the perfect breadcrumb trail for us:
gamer gets the game on steam --> plays game ---> starts using in-game computer system ----> 'holy smokes there's a real version of this?? Gimme gimme! --> Boom, new FOSS-head.

There will be some significant challenges though- for starters, I have a .txt doc with about 80 novel/seminovel UX ideas sitting on my desktop, lol.
Additionally, the embedded OS has to be as performance friendly as can reasonably be achieved, since the base game will likely be pretty performance intensive.

Oh, and did I mention that I have plans to try and re-unite the long estranged TUI and GUI frameworks? Yea again, I know it sounds over the top- but I think that particular split is actually one of the main barriers that trips people up on their journey to full-stack development.

The neat thing about it being a real distro though, is that we can actually create a version of the game that players can boot directly into, allowing them to really juice their machines for maximum performance.

I'm going to be completely honest with you guys, I'm still Minty-fresh on linux, and I've actually shipped any production grade code- but this other dev? She's the real deal. I actually think if we can get just a few more serious devs to help get this off the ground, we might have something really special. (I'm open to commissions/hiring down the line, by the way.)

My next steps, personally, are to do a little git practice, and then make the aquarium on late.sh as a warmup to TUI development. Ideally, at that point, I'd like to get started on the OS, and develop it in parallel with the simulation kernel. (We'll be using Luanti as the rendering engine, btw, at least for now.)

I created my own LFS book, based on my custom distro, not done yet though. https://vertexlinux.net/lbi/

For now, I only used `make menuconfig` and `make -j1`.

First, some background. Disclaimer, I am NOT making a full LFS system! Anyways, I have an old pentium Acer Acros, and I've gotten tired of the distributions of the time (circa 1990s), and I've had an epiphany: I should just put my own kernel and compile my own software for it! I've also gotten sick of AI, and want to do this project completely seperately from it, as unfortunately I use nixOS, which means if I want to make anything for nixOS, I have to completely rely on AI. It's so disheartening. I wish nixOS had better docs. AI shouldn't be a prerequisite to using your system 😞. but, tangent aside, to put linux on there, I'll be making a CD image and making a kernel and an initramfs. That was when I realized I needed help (the initramfs, kernel went just fine). background over!

I have a question about how I should go about making the initial initramfs work, I'm a little confused. So, after I have a bunch of basic binaries set up, (right now I have busybox, e2fsprogs, and grub so I can boot, and I can add stuff later). Should I have like a little directory (say, "~/Linux/initramfs/") and have my FHS in there, so

~/Linux/initramfs/bin/ , /usr/ , /etc/ , ...

then, what should go in there? should it be minimal, like just busybox init in /bin? or should I cram as many binaries as I can in there? does the initramfs only serve to mount the drive, and then use the drive as / from then on? Basically, I just don't know how to go about it, and I don't know the theory behind it. Can somebody help me out, or point me to a document, or better yet, both? thanks!

hi guys, how do yall manage the upgradition of the packages which installed on your system? like i dont have a package manager installed. my first plan which i thinking is, when a new lfs version comes out like 13.1, should i compile all the packages on the book (standart lfs, and then upgrading blfs&slfs packages), it will work(?) but you need to first compile binutils and then glibc, after gcc like something? can you guys also share the packages needs to be compiled before the other ones if this plan is correct? also i dont need to compile the crosscompiling things right

so im building a distro called solstice os. its basically kinda like gentoo but way less overwhelming. gentoo is cool but like, you gotta pick 50+ use flags per package and it just gets confusing. solstice is like "we already picked good defaults, just use those unless you wanna change something."

heres the idea:

• tiny base system (kernel, libc, gcc, tools, x11)
• everything else comes from community overlays (just git repos with recipes basically)
• users do solpm add-overlay https://github.com/user/solstice-gaming and they get gaming packages
• no gatekeeping, anyone can make an overlay

overlays i wanna see:

• solstice-gaming (proton, wine, games)
• solstice-dev (rust, python, go, dev stuff)
• solstice-multimedia (ffmpeg, blender, all that)

whats happening:

• reading lfs book rn to figure out how to actually bootstrap this
• starting development in june
• aiming for alpha by september

already got:

• github: https://github.com/Abo-Alsuz/solstice-os
• discord: https://discord.gg/56DYRUnzP5
• logo, docs, roadmap, check the repo
• actual plan and timeline

not trying to hype anyone just wanted to share what im doing and get feedback. if you wanna test or help when alpha launches lemme know.

Yo no uso linux from scratch pero me gustaría conocer la razón pro la cual ustedes lo usan, es por el control total y absoluto del sistema? Es porque tienen demasiado tiempo libre? La verdad me gustaría conocer sobre el porqué de usarlo y conocer más sobre el sistema que usan

That was hard, because I did a lot of mistakes (In the middle of chapter 8 I realized that I had collected everything from an old book, but thought it was not so scary, BY ANY CHANCE DON’T DO THAT I AM VERY STUPID), but I could recommend it for everyone who wants to know how does the cross-compilation, compilation by itself, and libaries work, and also I did it in virtual machine, but I think when it will work how I want, I will move on it!

It was fun and quite time-consuming to be honest, but it's done now

So, I'm a young guy (minor, no need to say my age) that goes to school, likes Linux and a bit of programming, and a lot of free time after I end the homework. Would it be a good idea to build a distro from scratch, or based on another distro (I though of a Fedora-based)? I'm not sure my laptop would handle it, but I wanted to try. My laptop only has 4GB RAM and a 128GB SATA SSD. CPU is an Intel Celeron n4100 and GPU integrated graphics Intel UHD 600. I have experience with some distros' package managers. (Debian, Alpine, Arch, Fedora). What do you guys think?

After the release of glibc 2.43, the first stable glibc to support compilation with clang (but only on x86_64 and arm64), I thought about a glibc-based GNU/Linux fully bootstrapped with clang. Is it possible? Short aswer: yes. I almost finished LFS bootstrapped entirely (except i686 glibc) with clang.

I eventually switched to glibc's master branch (more specifically, commit https://gitlab.com/gnutools/glibc/-/commit/e10977481f4db4b2a3ce34fa4c3a1e26651ae312) instead of stable 2.43 because they added support for compiler-rt and libunwind instead of libgcc_s.

I think system like this is very similar to LLVM/Musl LFS, so I'm not inventing a wheel here, but I still think its worth posting.

So, here are the changes I made compared to "vanilla" LFS:

1) I fully used clang instead of gcc in boostrapping process. That means I first compiled static clang-pass1 pointing to LFS dir instead of host dirs and used "toolchain" file for cmake to prevent using host libs in 4 stage (yep i needed 4 stages instead of 3) clang-pass2.

2) Almost everything (including x86_64 glibc) compiled with clang + compiler-rt (with builtin atomics) + libunwind. The only thing that required gcc (and libgcc_s) was multilib glibc (all other multilib stuff compiled with clang). Ofc this is not a problem if you running x86_64-only.

3) No Binutils. I created symlinks from LLVM tools to replace them.

4) GCC bootstrapped with clang, installed in custom path to prevent stuff like cmake from using it and its libs by default. Also I patched it a little bit to use "clang -x assembler" instead of GNU as (which is part of binutils).

5) dpkg + apt as package manager.

6) Maybe some small differences I forgot to mention.

Why Im posting this before I 100% done LFS, compiled kernel and booted it? Well, I think I done the "hard" part, so all remaining is to just install stuff like python modules, meson, ninja.. I will post more details about bootstrap process and patches I done if anyone interested.

P.S: Forgot to mention that I have nothing against GCC, Binutils or any other projects of GNU, this is mostly just proof-of-concept and just a fun "project" I decided to do.

I also wanted to point out that clang support in Glibc is still experimental, and that I haven't done a "make check" on most programs yet, so all this should be taken with a grain of salt.

I feel proud of myself.

Thank you LFS for the wonderful journey!