<SiFuh_>
dlcusa: No, I do not like the idea of going from gcc to bloatware compilers.
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux-musl
<farkuhar>
dlcusa: I prefer the language of "coexisting forks" rather than "conflicts being resolved" (by formal voting). There's no reason we can't have both CRUX-MUSL (with the gcc+binutils toolchain) *and* CRUX-LLVM/Clang (for those who want to try going without gcc). Users are welcome to contribute to whichever fork best suits their personal tastes.
<farkuhar>
For my part, I would enjoy the technical challenge of eliminating from pkgutils the subtle dependency on gcc, making it more compatible with alternative C++ compilers. But on my personal machine, I wouldn't want my main C++ compiler to be a bloated suite like LLVM/Clang.
<farkuhar>
I often see KISS Linux users describe their OS as a "metadistribution", meaning that there's no one source of truth regarding which software is part of the KISS project. Each user is free to decide, for instance, whether their toolchain is based around LLVM/Clang, or GCC.
<farkuhar>
So in a way, there are as many coexisting forks of KISS Linux as there are users. All these users are "voting with their feet" and taking personal responsibility for what they install, rather than engaging in a formal voting process where some core team has enumerated the available choices for satisfying the distro's goals.
<farkuhar>
An update on the Clang/Rust/Firefox issue: After several days of slowly rebuilding all the Firefox dependencies from a core-only install, I still hit the same error during the gecko-profiler target ("the libclang shared library at /usr/lib/libclang.so.19.1.7 could not be opened: Dynamic loading not supported").
<farkuhar>
So I think there must be something wrong with the way I built llvm, clang, and rust.
<farkuhar>
It would have been silly if the previous failures were traceable to the shared directory $PKGMK_SOURCE_DIR/rust being contaminated with build artifacts from earlier firefox versions (in the same way that prt-get/src/.deps was contaminated with automake leftovers from CRUX-glibc). So I guess it's a good sign that the same build failure occurs, if it forces me to revisit the llvm, clang, and rust dups in the MUSL overlay.
<farkuhar>
On my old CRUX-MUSL installation, I also tried building firefox 137 using the port of llvm-project from emmett's KRAKEN distro (the port that bundles together llvm, clang, lld, and compiler-rt). The same failure was triggered during the gecko-profiler target, so maybe it's a problem that needs to be addressed in the firefox port.
<farkuhar>
I think KRAKEN is one of emmett's recent efforts to create a distro without gcc. Perhaps the complete reliance on LLVM and Clang (instead of gcc+binutils) is what allows the firefox build to succeed, whereas on CRUX-MUSL some ports are built in a way that triggers the error "Dynamic loading not supported".
<SiFuh_>
KRAKEN isn't emmetts
<farkuhar>
Actually, according to this screenshot https://0x0.st/8OKY.png it should be possible for gcc and LLVM/Clang/Rust (on CRUX-MUSL, not KRAKEN) to cooperate in a successful build of firefox 137.0.1. I just seem to be working with a slightly different configuration of the toolchain, and the subtle differences are breaking the build.
<SiFuh_>
farkuhar: emmett made KRAK3N not KRAKEN
<farkuhar>
emmett's older repo has LLVM and Clang at version 18.1.8 (https://codeberg.org/emmett1/crux-musl/src/branch/main/llvm/Pkgfile for example). I don't recall seeing the latest llvm or clang in ukky's overlay, either. So I adapted the latest {llvm,clang,lld,rust} ports from opt/3.8, using emmett's crux-musl overlay as my guide.
<farkuhar>
SiFuh_: sorry about KRAK3N versus KRAKEN. I guess I should have asked for more leeway to make spelling mistakes.
<SiFuh_>
Nah, I want to pedantic like you and I... Oh is that like GNU ;-)
<farkuhar>
The latest rust hasn't been pushed to that repo yet, but rust#1.86 is what I have installed, and it works fine for building almost everything *except* firefox.
<farkuhar>
Something I re-learned about the xorg/mesa port while working my way up from a core-only install: you might hit a build error if you install only the hard dependencies. It's essential to consult the mesa README.md to determine which optional dependencies must be installed, based on the target video card.
<farkuhar>
It's gotchas like those that make me impressed even more by darfo's practice of always building in a clean container (with none of the optional dependencies present). What if more ports start going the way of xorg/mesa, and darfo has to introduce workarounds for each of them to keep up the practice of clean-container builds?
<farkuhar>
Heh, the prt-get repo on my CRUX-MUSL laptop had an unpushed commit from 2024-08-09 "fix missing include on non-glibc systems". I should have stuck with one computer for all the development work, rather than switching between laptop and desktop according to which one was powered on that day.
<SiFuh_>
farkuhar: I kept it private from zorz and lavaball.
<remiliascarlet>
farkuhar: Why not make a Linux distro that uses tcc or scc?
<SiFuh_>
Because they will turn your channel into a shit mess
<farkuhar>
SiFuh_: I can understand the concern about lavaball, but why exclude zorz? It's distro-hoppers like him whose perspective would be useful when designing a fork.
<SiFuh_>
You're the boss farkuhar. It's your channel
<remiliascarlet>
Zorz can be a bit of an idiot at times, but at least he's not an outright creep.
<SiFuh_>
remiliascarlet: Hahahaha sometimes? I find him to be an idiot all the time. But yeah. Zorz is fucking funny and not a creep
<SiFuh_>
He makes my days sometimes.
<dlcusa>
So, (farkuhar SiFuh emmett) your goal is, from a users' perspective, multiple core distros w/core-specific docs or a single core distro with boottime configuration and one doc?
<SiFuh_>
dlcusa: For me it is a distro that can run on multi cores. No documentation except online and man pages. And no crap that sits on my system that I never need. "Per's" concept.
<SiFuh_>
dlcusa: I just wish Linux manpages were as perfect as OpenBSD's straight to the point, with examples that are commonly used.
<farkuhar>
emmett: I got a successful build of pkgutils with CXX=clang++ instead of g++ (and no sourcing of gcc-specific headers). See today's commit f3164d0d4a743880c66953f75e8f6125a62992a7 in my forked repo for the details.
<farkuhar>
Gotta celebrate the small successes, or SiFuh_ will start accusing me of using this channel solely for complaints.
<farkuhar>
I haven't yet tested the changes on a typical-size pkgdb. I might have introduced a significant slowdown by not slurping up the file as fast as the pagesize will allow. On the other hand, maybe modern C++ compilers are smart enough to apply the necessary optimizations, bringing performance to the same level as before.
<farkuhar>
For a pkgdb with 270 installed packages, if there is any slowdown between the original pkgadd and the one that emmett requested, it's smaller than the precision level reported by /usr/bin/time (without adjusting the format string). pkginfo requests are all taking about 00.08s (=00.07s user + 00.01s system) regardless of which version I run.
<SiFuh_>
farkuhar: Have you hacked emmett and my Telegram?
<farkuhar>
SiFuh_: No, why do you ask?
<farkuhar>
If anyone should be worried about his system getting hacked, it's zorz. He's the one who made files under /sys/class/backlight/amdgpu_bl2/ world-writable, setting himself up for getting blinded when a malicious user hacks in and maximizes the brightness while his eyes are adjusted to a dark room.
<SiFuh_>
farkuhar: nothing ;-)
<farkuhar>
SiFuh_: the way I'm reading dlcusa's question about "multiple core distros", it has nothing to do with multi-core CPUs, but instead refers to my claim that multiple alternatives to CRUX-glibc can all coexist simultaneously. Some users might prefer only replacing glibc with musl, not going as far as to eliminate gcc/binutils in favor of llvm/clang. Other users might want to replace both glibc and gcc (and openssl?).
<farkuhar>
I do agree with dlcusa that each fork should have a clearly-defined identity (i.e., a set of goals and priorities), so that users can make an informed choice.
<farkuhar>
Once the fork has settled on its identity, there shouldn't need to be too much effort at customizing the documentation. The official CRUX handbook can be used as a starting point, with footnotes added where the fork has chosen to do things slightly differently.
<farkuhar>
If I'm reading dlcusa's question correctly, then I would go on to say that "core distro" is unnecessarily restrictive. Yes, we do want to offer all users a slimmed-down collection of core packages, but there's no reason we can't go further and maintain an overlay for each fork, so that popular packages in the {opt,xorg,contrib} repos can still be installed by the users.