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