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/
farkuhar has quit [Quit: leaving]
SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #crux-musl
farkuhar has joined #crux-musl
<farkuhar> Appending --enable-pcre2 to the configure invocation is not the only way to fix the build failure of opt/fdm on CRUX-MUSL. You could also make up for the absence of REG_STARTEND in /usr/include/regex.h with a sed command on fdm.h. But the omission of --enable-pcre2 should be corrected on CRUX-glibc anyway; otherwise the dependency line is misleading.
<farkuhar> opt/fdm is similar to core/gdbm in that manner; it's wasteful to carry around a dup in a MUSL overlay when the official port could be improved and made more broadly compatible.
<farkuhar> Without the --enable-pcre2 option passed to configure, the gcc command that builds opt/fdm will not contain -lpcre2. Even if the resulting fdm binary made use of libpcre2 at runtime, the lack of any dynamic linking means that libpcre2 (a core port) appearing in the "Depends on" header is a violation of distro policy.
<SiFuh_> Yeah that shits me. When morons put depend lines in and some are core ports.
<farkuhar> Hmm, speaking of slinging insults at members of the core team, does anyone remember why stenur called beerman a terrorist?
<SiFuh_> Because he was constantly insulting, abusing stenur and ignoring and blocking stenur's work.
<emmett> farkuhar: how it goes with your clang/llvm/rust/firefox issue?
<emmett> i'm just done rebuilding CRUX-MUSL 3.8 on my laptop
<SiFuh_> Fake ;-)
<emmett> SiFuh_: ofcourse its fake
<farkuhar> emmett: still a long way to go. $(prt-get depends firefox | grep -c '\[ ') = 50 at the moment, and two of those 50 pending builds will occupy the better part of a day. I'm taking it slowly, to document thoroughly all the fixes I need to apply starting from a core-only install.
<emmett> hmm okay
<emmett> btw does 'prt-get dependent' works on your CRUX-MUSL?
<farkuhar> yes, it works as designed.
<SiFuh_> Would be weird if it didn't. Sure you were not tlaking about revdep?
<emmett> does 'prt-get' compiled fine? It failed for me, and i need sed to fix it. maybe thats the caused my 'prt-get dependent' not working on CRUX-MUSL
<farkuhar> To elaborate: `prt-get dependent $arg` only looks at the Pkgfiles of the installed ports (in the active collections) and prints the port name if $arg was listed as a dependency. There's no inspection of the actual linking in the binaries.
<emmett> yes, but it does not work for me. 'prt-get dependent <any pkg>' prints nothing
<SiFuh_> There is no package or port called <any pkg>
<farkuhar> hahaha
<emmett> error log for prt-get
<farkuhar> emmett: I don't build the official prt-get (v5.19.6) on any of my systems, I just populate /usr/bin with a symlink to the compiled prt-get in my git repo (mirrored at https://git.crux.nu/farkuhar/prt-get). Whichever branch I compiled most recently is the variant that gets executed.
<emmett> your version also failed to compiled
<emmett> farkuhar: same error
<farkuhar> Hmm, maybe the ctime header gets included automatically, given the layout of /usr/include that comes with ukky's ISO. If you spin your own ISO, then /usr/include might look slightly different.
<emmett> so, does it compiled fine on your system?
<SiFuh_> yes emmett it compiles fine on our systems
<farkuhar> emmett: yes, because our systems all have gcc. What does `grep -lr ctime /usr/include/` print for you?
<emmett> my CRUX-MUSL still have gcc
<SiFuh_> Wasn't there a ctime in the old MUSL source?
<emmett> farkuhar: http://0x0.st/8OPJ.log
<farkuhar> emmett: Since the grep command prints /usr/include/c++/14.2.0/x86_64-pc-linux-musl/bits/stdc++.h among the hits, look inside to confirm that it has "#include <ctime>"
<emmett> farkuhar: yes, it has "#include <ctime>"
<farkuhar> appearing unconditionally, right? (not protected inside an #ifdef)
<emmett> yes correct
<farkuhar> then I'm surprised you hit those errors when compiling prt-get. Anyway, you found a simple fix at the Pkgfile level, so it's not a big deal.
<emmett> yes those simple fix make prt-get compiled, but then a few prt-get function does not work
<emmett> what i'm noticed, 'prt-get dependent' and '/etc/prt-get.aliases' does not work
<farkuhar> if you want a Perl reimplementation that does mostly the same thing as prt-get, you can try this one: https://git.sdf.org/jmq/Documentation/src/commit/8f7c8f592b33591201fbdc22ace1cef03460f6a0/scripts/prt-auf
<emmett> no, i'm just tring to help CRUX-MUSL, if its working fine for you than its ok
<emmett> CRUX-MUSL is not my main daily drive distro anyway
<emmett> if i want, i would write my own prt-get implementation in POSIX sh
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux-musl
<farkuhar> Somebody should tell hermit_crab about the #crux-social channel.
<SiFuh_> farkuhar: better you tell him about crux-musl or lavaball
<farkuhar> More thoughts on emmett's failed build of prt-get: I notice that he configures llvm-project with -DCLANG_DEFAULT_CXX_STDLIB=libc++ (overriding the default "libstdc++"), so maybe he invokes gcc with a different value for -std= too. That might be enough to prevent the ctime header from being pulled in during the build.
<emmett> farkuhar: whatt??
<emmett> where did i change stdlib? I never told you i changed stdlib
<emmett> I already said this is gcc CRUX-MUSL
<emmett> so prt-get still compiled using gcc
<emmett> i dont know where you get that assume
<farkuhar> emmett: I'm referring to your KRAK3N distribution, specifically https://codeberg.org/emmett1/KRAK3N/src/branch/main/llvm/abuild#L52
<farkuhar> I agree, it's an unfair assumption that your CRUX-MUSL also overrides the default flag -std= when invoking gcc. I was just thinking out loud, what might possibly explain that "#include <ctime>" was not being processed in your failing builds.