SiFuh_ changed the topic of #crux-musl to: CRUX 3.7 MUSL | Homepage: https://crux.nu/ | Ports: https://crux.nu/portdb/ https://crux.ninja/portdb/ | Logs: https://libera.irclog.whitequark.org/crux-musl/
<emmett> farkuhar: those two is completely different projects.
<emmett> i still cant do LLVM/Clang on CRUX-MUSL, i still waiting for your pkgutils code fix about 'gnu_gcc' i told you before.
<emmett> s/gnu_gcc/gnu_gxx/
<emmett> since you told me you are using precompiled prt-get on your CRUX-MUSL, is it compiled on CRUX-glibc?
<emmett> if not, can you compile prt-get on CRUX-MUSL now to make sure theres no error?
<farkuhar> emmett: SiFuh_ already told you that prt-get compiles fine on our systems. AFAIK none of us are cross-compiling on CRUX-glibc, or precompiling prt-get somewhere else.
<farkuhar> The CRUX-MUSL that we're using is installed from the ISO that ukky built, not the rootfs tarball that you created. We wanted to follow the official ISO build procedure as much as possible, to introduce fewer deviations from CRUX-glibc. It's those extra deviations that might be the cause of your prt-get build errors.
<SiFuh_> farkuhar: Actually it was I that wanted to follow the official ISO. ukky's version is close but wasn't built the same.
<farkuhar> emmett: Here are further details on how SiFuh_ managed to build a CRUX-MUSL 3.7 ISO. https://gitlab.com/SiFuh/Documentation/-/blob/master/Musl/CRUX-MUSL.txt?ref_type=heads
<SiFuh_> farkuhar: He already knows. He was with me building it at that time :-P
<SiFuh_> farkuhar: emmett and I did all the work through Telegram
<farkuhar> SiFuh_: Did Telegram also facilitate your work with ukky? I don't recall seeing anything in the public forums to indicate that ukky took more liberties than you did, in adapting the official ISO procedure for CRUX-MUSL.
<farkuhar> I do recall a brief exchange about how the ownership of certain files would be distributed between gcc and linux-headers, but you and ukky were mostly in agreement there too.
<SiFuh_> farkuhar: ukky and I agree on a lot of things. Like he is my family. But actually you were non-existant for much of our conversing. And no Telegram wasn't used
<farkuhar> SiFuh_: non-existant, or not paying attention. Just like I seem to have missed emmett's request for a "pkgutils code fix about gnu_gxx". The closest match in my recollection is a request to tweak pkgutils so that it could compile on systems without gcc.
<farkuhar> It was the gratuitous use of stdio_filebuf that introduces a gcc dependency. If emmett wants pkgutil.cc to be compilable on a system with only llvm+clang, then the stdio_filebuf functions will have to be rewritten in terms of lower-level fstream primitives.
<emmett> farkuhar: Just so you know, ukky's prt-get port also faced issue as mine, as link given by Sifuh here: https://libera.irclog.whitequark.org/crux-musl/2025-04-14#38022051
<emmett> and patched to fix '#include <ctime>' issue on musl.
<emmett> So ukky's and I on the same boat.
<emmett> My CRUX-MUSL projects is completely follow Official CRUX (if you stop misleading with my other projects)
<farkuhar> What confuses me is how this gcc dependency would lead to "i still cant do LLVM/Clang on CRUX-MUSL", because as far as I can tell, emmett's crux-musl distro still has gcc.
<SiFuh_> ........
<emmett> My CRUX-MUSL is using official CRUX ports, then only include needed musl fix patch, including official prt-get
<SiFuh_> farkuhar: Are you speed reading again?
<SiFuh_> farkuhar: He said he has a gcc system with the issue.
<emmett> You see, its you that deviation from CRUX-glibc by using precompiled prt-get from nowhere as you stated here: https://libera.irclog.whitequark.org/crux-musl/2025-04-17#38037244
<SiFuh_> 23:53:28 [emmett> my CRUX-MUSL still have gcc
<SiFuh_> 07:16:50 [emmett> I already said this is gcc CRUX-MUSL
<emmett> farkuhar: yes, my crux-musl is still using gcc
<SiFuh_> 07:17:01 [emmett> so prt-get still compiled using gcc
<SiFuh_> emmett: See what I mean?
<emmett> SiFuh_: hahahaha
<farkuhar> emmett: I didn't mean to imply that my prt-get was "precompiled". Now it's you who's speed-reading.
<emmett> i could get headache right now..haha
<emmett> farkuhar: "I just populate /usr/bin with a symlink to the compiled prt-get in my git repo"
<SiFuh_> farkuhar: Is good at giving them to me. Take your turn emmett, share my burden too
<emmett> isn't precompiled if by populate /usr/bin with a symlink to the compiled prt-get in my git repo?
<emmett> hmmm
<farkuhar> emmett: What I said was, I didn't install prt-get as a port. I just run `make all` in my local repo, and then the symlink under /usr/bin is pointing to the most recently compiled version (natively compiled on CRUX-MUSL, though I didn't think I had to spell it out so explicitly).
<SiFuh_> emmett: Well it does say precompiled with a compiled version. So technically it would be compiled
<farkuhar> And in my local repo, src/package.h does not have "#include <ctime>", yet `make all` still works fine on CRUX-MUSL.
<farkuhar> Can we get back to your claim "cant do LLVM/Clang on CRUX-MUSL"? They both build fine for me. And that's without any "pkgutils code fix about gnu_gxx" (which seems to be an entirely unrelated issue).
<emmett> farkuhar: alright, how your prt-get can get compiled?
<emmett> farkuhar: these two is two different issues
<emmett> 1. how is your prt-get does not error when compiling on CRUX-MUSL
<emmett> 2. my claim "cant do LLVM/Clang on CRUX-MUSL" is just saying i'm not doing LLVM/Clang for CRUX yet, because i'm waiting your fix for pkgutils
<emmett> farkuhar: can you confirm to me that your version of prt-get is compiled fine on your CRUX-MUSL system?
<SiFuh_> On my old system that I deleted, I can confirm it.
<farkuhar> emmett: how my prt-get can get compiled? Apparently there was a hidden subdirectory src/.deps (timestamp 2023-12-01) containing prtget.Po, and that's how the ctime header was getting pulled in automatically.
<farkuhar> Note that the reference to ctime in src/.deps/prtget.Po referred to an even older gcc version (12.3.0), but the header was in the same relative location, so the leading directory components didn't need to be accurate for the header to get pulled in.
<emmett> farkuhar: owh okay. so what if you 'make clean' then build again
<emmett> does it build fine?
<farkuhar> emmett: Heh, the Makefile isn't comprehensive enough to remove src/.deps when you run `make clean`. I had to rename src/.deps in order to hit the error.
<emmett> owh okay, thats fine, any ways should do it. I just need you make a clean buuild
<farkuhar> So my problem was, never trying to build prt-get as a port, but always relying on the development branch in my local repo. Of course I wouldn't hit those errors that start from a clean unpacked tarball.
<emmett> so, your prt-get faced issue on musl too?
<SiFuh_> emmett: faced. Hehehehe
<farkuhar> Only when building as a port. In the local repo still holding artifacts from the 2023-12-01 build, the errors were avoided thanks to the hidden directory src/.deps
<SiFuh_> So you faced the prt-get issue on musl too?
<farkuhar> After renaming the hidden directory, then yes, I managed to reproduce your ctime error.
<farkuhar> I guess it is fair to describe the state of my local repo as "precompiled", as in "having build-time artifacts from previous development cycles" (some on CRUX-glibc, perhaps). Who would have expected them to be so sloppy when writing the Makefile, as to forget about the hidden directory src/.deps?
<farkuhar> I should add another target to Makefile and src/Makefile, so that `make distclean` would delete even the hidden directory src/.deps (or maybe just incorporate this deletion into the existing target `make clean`).
<emmett> SiFuh_: okay teacher
<SiFuh_> Hahaha okay pupil!
<emmett> farkuhar: yeah, thats why i called precompiled, based on what you said.
<emmett> i will wait for pkgutils gnu_cxx issue to be fixed then i will start building LLVM/Clang CRUX
<SiFuh_> Why the need for LLVM/Clang? What is wrong with removing all that crap and just sticking with gcc?
<farkuhar> Hahaha, my prt-get/.git/info/exclude actually lists the hidden directory .deps, so I wasn't pushing to the remote repository all those build artifacts that might have made compilation possible without the insertion of "#include <ctime>"
<farkuhar> SiFuh_: some people want to move away from gcc, and do everything with LLVM/Clang, for similar reasons that motivated your replacement of openssl with libressl. There was that blog post from a few days ago, for example, disparaging gcc as "ancient technology": https://mcyoung.xyz/2025/04/14/target-triples/
<SiFuh_> farkuhar: They are not similar reasons to why I chose libressl over openssl
<farkuhar> SiFuh_: Remind me again, what were the reasons for choosing libressl over openssl?
<SiFuh_> ....
<SiFuh_> Openssl was broken so badly OpenBSD guys stepped in and looked at it went "yeah fuck this" and they made their own version.
<farkuhar> I think the LLVM advocates are saying that GCC is so badly broken, when it comes to cross-compiling, that they react with "yeah fuck this" and come up with their own solution.
<SiFuh_> You can entertain that notion if you desire
<farkuhar> I don't do any cross-compiling myself, thus I have no direct experience with which to compare LLVM/Clang against GCC on that front. So if emmett wants to do a fork of CRUX with no GCC, who am I to raise objections?
<SiFuh_> I'd like to see it too
<dlcusa> Hmmmm... it sounds like emmett, SiFuh, and farkuhar agree no gcc in first crux-musl rc is a goal, yes?
<farkuhar> dlcusa: I think emmett proposed a new name like CRUX-LLVM/Clang, to distinguish it from the original CRUX-MUSL (which only replaced glibc, leaving intact the gcc+binutils toolchain).
<farkuhar> If you haven't noticed, emmett has a long history of creating distros based off of CRUX. One of the earlier efforts was Venom Linux, followed by CRUX-MUSL, and lately he's worked on the Alice Linux distro. CRUX-LLVM/Clang is just another itch he needs to scratch.
SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #crux-musl
<dlcusa> I don't care about the name so much, as long as it's descriptive--what makes this CRUX different from all other CRUX (CRUXes?).
<dlcusa> The point remains: goal of release candidate includes no gcc support in core.
<dlcusa> I've been thinking about voting more and think it's important to assign weights to goals such that conflicts are resolved by which is weightier. Also, participants' votes are weightier if they are doing more to create the release. All details to be hammered out.
<farkuhar> dlcusa: only the most engaged users would participate in a formal voting process. Everyone else seems to "vote with their feet" and hop to whichever distro meets their own personal goals. And these goals can change over time, so that the distro you happily used in 2004 is not what you want to run in 2025.
<farkuhar> The fact that emmett is continually coming up with new distros does not mean that the earlier projects are abandoned. They can all coexist like reference volumes on a bookshelf, which you pull down from time to time and then put back until they're needed again.
<dlcusa> I'm talking about the most engaged, those who improve the distro--it's about ensuring the most committed have the most say, in a stated policy that documents how it is, so anyone that might care knows.