Page 2 of 2
Re: Crux Linux!
Posted: Thu Nov 20, 2025 3:47 am
by Grogan
I just couldn't behave myself any longer. It's been bugging me from the start, but I'm sick to death of having old guts in this distro, that prevent me from having binary compatibility with Arch. Most of the ports are pretty current, but the glibc 2.40 and gcc 14 (libstdc++) are showstoppers.
So I copied the core ports for glibc, gcc and binutils and modified them to work with glibc 2.42, gcc 15.2.1 (from git commit) and binutils 2.45. I removed inappropriate patching and kept necessary things like patching for lib vs. lib64 (like Arch, they don't use lib64). I adjusted the glibc build to use Linux 6.17 kernel headers (instead of their Linux 6.6.30 headers). It was all very easy to do and nothing fought me at all, but I found some of their $name $version type substitutions to not work out so I replaced them with actual names and versions. It means I'll have to do a bit of editing every time, but oh well. I changed some of the build options for performance (v.s. security) in glibc and gcc since I'm driving now.
I used "prt-get lock pkgname" for those packages like I did for Mesa so that prt-get won't touch them.
Also, to my CFLAGS in /etc/pkgmk.conf I added "-Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types" in case some of the ports run afoul of gcc 15's stricter behaviour.
I bootstrapped the GNU stuff (compiled twice in order, rebooting for glibc), rebuilt gnu make and libtool and everything seems to be fine. I did my first "prt-get sysup" and it built a bunch of updates (i.e. my toolchains are all working fine) including LLVM/Clang 21.1.6 which I'd have redone after all this anyway.
Now I'll be able to run my firefox builds from Arch here, though I still have to compile it once more because Mr. Practical here disabled Alsa. I also won't have to worry about common build tools that I keep /storage2/shit/build (I was being careful to compile those on Crux so they can run on both)
Now it feels more like it's MY system

Re: Crux Linux!
Posted: Thu Nov 20, 2025 5:02 am
by Zema Bus
Re: Crux Linux!
Posted: Mon Dec 15, 2025 10:19 pm
by Grogan
Fuck... last night, an update to alsa-utils broke my audio (couldn't open pcm device). The last thing I do before I go to sleep is watch a few youtube videos to get sleepy and... silence. My audio player (audacious) was just erroring out on snd_pcm_open. (all audio playback would be broken by this)
I spent hours on this. First I tried removing and regenerating my asound.state (and alsamixer was working correctly), then recompiled alsa-lib, alsa-utils again, alsa-plugins. I installed alsa-ucm-conf so diagnostic utilities would work. I tried going back to the previous alsa-utils 1.2.14, recompiling everything again starting with alsa-lib. Damnit, everything looked correct. alsactl init and alsactl store etc. were working correctly (mixer device), showing the correct kernel devices and the correct one as default, but nothing could open the audio device. I looked in /dev and the audio devices were there with the correct permissions and /proc/asound seemed correctly populated too. There really wasn't any configuration amiss that I could see, none of the files in /etc/alsa/conf.d (symlinks to /usr/share/alsa/alsa.conf.d) looked wrong (and most of that shit doesn't apply to me)
I finally had to give up, and went back to Arch to relax, but it kept me awake until after 9 AM when I finally fell asleep at the computer, because I was pissed off. Shit like that also causes me to smoke more cigarettes.
Today I was going to unpack an older backup tarball to compare files, but first I checked to see if they fixed it and they somehow did. There was an update to alsa-lib (that they didn't update to 1.2.15 last night) and I notice that it patches a lot of card db type stuff. So I built that, and then alsa-utils and alsa-plugins again (which prt-get or anything doesn't tell you to do) and it's back to normal
It still doesn't explain why I couldn't fix it this morning by rebuilding what I had (it certainly worked before that) but I've wasted enough time on this. All I can figure is that the installation of (a new) alsa-utils broke some needle-in-haystack configuration data and then going back to the old versions of alsa packages (ports) didn't put it back.
I've never had a problem with ALSA before, not even on that last LFS system that I maintained and upgraded by hand for years. I've always thought of standalone ALSA as being reliable, compared to pusaudio and pullwire type front ends, but nothing is immune to distro fuckery.
Re: Crux Linux!
Posted: Tue Dec 16, 2025 6:32 am
by Zema Bus
Things like that always seem to happen just before bedtime. When it does I always know I'm either going to lose sleep trying to sort it out or go directly to bed and lose sleep thinking about it lol!
Re: Crux Linux!
Posted: Tue Dec 16, 2025 7:48 am
by Grogan
Exactly, always before bed is the time that problems are often discovered. In this case it's hardly surprising though, as I update Crux at that time every night
It's like this. When I'm finished gaming around 6'ish, I reboot to Crux and update the ports tree and see what packages need upgrading, then I let it go and have a smoke and it's all done compiling unless something big was in the list. After that, I watch some youtube and get lulled into somnolence. So that was rather disruptive.
Re: Crux Linux!
Posted: Tue Dec 16, 2025 12:28 pm
by mlangdn
Several at LQ had problems with alsa after an update. I wasn't affected for whatever reason other than the volume was turned down after the update. Increased volume back to where I had it and no problems. Maybe your problem is somewhere here.
https://www.linuxquestions.org/question ... 175756485/
Re: Crux Linux!
Posted: Tue Dec 16, 2025 5:26 pm
by Zema Bus
Looks like I inadvertently dodged that bullet, I updated Slackware-Current yesterday after not updating for a few weeks, and have 1.2.14. This was right after alsa-utils was reverted the day before on Sunday:
Sun Dec 14 21:36:39 UTC 2025
ap/alsa-utils-1.2.14-x86_64-1.txz: Upgraded.
Looks like this also needed to be reverted along with alsa-lib.
Thanks to TommyC7.
l/graphviz-14.1.1-x86_64-1.txz: Upgraded.
xap/xsnow-3.9.0-x86_64-1.txz: Upgraded.
Re: Crux Linux!
Posted: Tue Dec 16, 2025 8:30 pm
by Grogan
It seems that people were having all different problems with ALSA on Slackware in that thread.
Reverting mine didn't work, as I said, it screwed something up. I'm pure alsa though, no pulseaudio. I have alsa-lib 1.2.15 and alsa-utils 1.2.15, but my alsa-lib on Crux has an extensive patch. It was probably inappropriate patching. Just because you can get patches to apply (and even compile) doesn't mean they are correct. (I run into that a lot with Wine patches lol)
Arch's PKGBUILDs have been upgraded to 1.2.15, but it's not being pushed out to updates yet. On Arch I use pulseaudio though (but not pipewire). I'm just using distro packages for that, I guess I should take over that too so they can't yank the rug out from under foot. I've never had a problem with ALSA before.
Re: Crux Linux!
Posted: Sun Jan 11, 2026 9:43 pm
by Grogan
LOL... after falling asleep playing games, around 6'ish I started working on my GNU toolchain in Crux, to bring glibc, binutils and gcc up to the same commits as Arch. I didn't anticipate the problems I was going to have because I removed their 32 bit glibc that came with the base system (after the fact, I don't use anything lib32 and initially forgot that it was installed). It was only there because their gcc was built with multi-arch, as was my first 15.2.1 upgrade because the old lib32 glibc was still there. That meant my new binutils built without multilib support (good), but then my gcc wouldn't compile. I just have to have things my way... no default PIE and stack protector output (SSP), no Intel CET (I disable that in binutils, glibc and gcc). I can't stand distro dogfood. Stuff like PIE executables and such should be up to individual projects to turn on appropriately. Opt-in.
I had removed --enable-multiarch in anticipation but I found out it's also necessary to --disable-multilib which is implied by that. It failed on including a binutils header, /usr/include/gnu/stubs-32.h which of course wasn't present. OK... start the build again, should be fine now, but I kept missing shit in the Pkgfile, like $PKG/usr/lib{,32} which means do whatever in both lib and lib32. Any failure causes it to delete the Work directory and you have to start the pkgmk over.
In total, because of my mental state, I think it took me 4 tries to get this right. I'd like fix something, make sure there are no more instances of it, run my eyes through the rest and miss different things, start pkgmk again then start watching some youtube shorts while waiting. It kept me up past 9 AM, and of course THEN I couldn't get to sleep. I should have left it for today
I also made it harder on myself by changing $version to reflect the revisions. It's a git checkout rolled into a tarball that I named so $name-$version.tar.xz would work out, while the directory name is "gcc" instead of "gcc-$version". So I had to hard code some 15.2.1 shit that I'll have to remember next time that changes.
The gcc-4.7.3-multilib-dirs.patch is still necessary to correct some "lib64" paths in certain places (and some are changed with sed).
I debated whether or not to change --with-pkgversion="CRUX-x86_64-multilib" but decided to leave that in case something else in the distro cares about that string, even though the compiler isn't multilib anymore (I've never built anything 32 bit on this system). Ahh well, it's simplified now.
Code: Select all
# Description: The GNU Compiler Collection
# URL: https://gcc.gnu.org
# Maintainer: CRUX System Team, core-ports at crux dot nu
# Depends on: libmpc zstd
name=gcc
version=15.2.1-r447
release=1
source=($name-$version.tar.xz $name-4.7.3-multilib-dirs.patch)
build() {
patch -d gcc -p1 -i $SRC/gcc-4.7.3-multilib-dirs.patch
sed -e '/m64=/s/lib64/lib/' -i $SRC/gcc/gcc/config/i386/t-linux64
# pipe fails tests
CFLAGS=${CFLAGS/-pipe/}
CXXFLAGS=${CXXFLAGS/-pipe/}
mkdir build
cd build
../gcc/configure \
--prefix=/usr \
--libexecdir=/usr/lib \
--enable-threads=posix \
--with-build-config=bootstrap-lto \
--with-linker-hash-style=gnu \
--with-system-zlib \
--enable-languages=c,c++,lto \
--enable-stage1-languages=c,lto \
--enable-link-serialization=1 \
--enable-linker-build-id \
--enable-gnu-indirect-function \
--enable-__cxa_atexit \
--enable-clocale=gnu \
--enable-shared \
--enable-lto \
--enable-plugin \
--disable-cet \
--with-pkgversion="CRUX-x86_64-multilib" \
--with-x=no \
--disable-fixincludes \
--disable-multilib \
--disable-nls
make -O -j24 STAGE1_CFLAGS="$CFLAGS" \
BOOT_CFLAGS="$CFLAGS" \
BOOT_LDFLAGS="$LDFLAGS" \
LDFLAGS_FOR_TARGET="$LDFLAGS" \
bootstrap
make -j24 DESTDIR=$PKG install
install -d $PKG/lib
ln -sf ../usr/bin/cpp $PKG/lib/cpp
ln -sf gcc $PKG/usr/bin/cc
ln -sf g++ $PKG/usr/bin/c++
################# Don't forget to edit these hard coded versions ################
rm -r $PKG/usr/share/{info,gcc-15.2.1}
rm -r $PKG/usr/bin/*-linux-gnu-*
rm -r $PKG/usr/lib/gcc/*/15.2.1/{install-tools,include-fixed}
for D in lib; do
install -d -m 0755 $PKG/usr/share/gdb/auto-load/usr/${D}
mv $PKG/usr/${D}/libstdc++.so.*-gdb.py $PKG/usr/share/gdb/auto-load/usr/${D}
done
mkdir $PKG/usr/lib/bfd-plugins
ln -sfv ../../lib/gcc/$($PKG/usr/bin/gcc -dumpmachine)/15.2.1/liblto_plugin.so \
$PKG/usr/lib/bfd-plugins/
sed -i "s|-L$SRC[^ ]* ||g" $PKG/usr/lib/{libstdc++.la,libsupc++.la}
}
Re: Crux Linux!
Posted: Fri Feb 27, 2026 8:53 pm
by Grogan
So I played a game for the first time on this Crux setup. I chose Unreal Tournament 2004, because it's probably the only thing that would run out of the box (I didn't install any libraries for games) and I haven't seen it in a long time. The reason it still runs is because I have the old 64 bit libraries in the game dir that the 2006 update needs. I can't believe they are still valid.
Code: Select all
lrwxrwxrwx 1 grogan grogan 17 Sep 21 2010 libartsc.so -> libartsc.so.0.0.0
lrwxrwxrwx 1 grogan grogan 17 Sep 21 2010 libartsc.so.0 -> libartsc.so.0.0.0
-rwxr-xr-x 1 grogan grogan 23600 Feb 28 2008 libartsc.so.0.0.0
lrwxrwxrwx 1 grogan grogan 20 Sep 11 2017 libSDL-1.2.so.0 -> libSDL-1.2.so.0.11.4
-rwxr-xr-x 1 grogan grogan 422752 Sep 11 2017 libSDL-1.2.so.0.11.4
lrwxrwxrwx 1 grogan grogan 18 Sep 21 2010 libstdc++.so.5 -> libstdc++.so.5.0.6
-rwxr-xr-x 1 grogan grogan 4495476 May 25 2006 libstdc++.so.5.0.6
-rwxr-xr-x 1 grogan grogan 263920 Sep 27 2010 openal.so
I always preserve timestamps when copying/archiving, so I can see when those libraries were compiled. Ignoring the dates on the library symlinks (I created those later), the oldest thing is libstdc++.so.5 compiled in 2006. I can't believe that's still valid, a 64 bit build of gcc 3.x was lucky to succeed even in those days. I dropped in newer libSDL 1.2 and openal builds at some point over the years. Those libartsc libraries came from an old KDE 3 build. They are a dependency for being able to operate with that audio server, otherwise unused, but they have to be there.
I simply copied ~/.ut2004 and ran the ut2004 wrapper script in the game dir, and it didn't miss a beat. It even remembered the last map I played.
Now THAT is robust, mostly owing to backward compatibility of system libraries like glibc. In 20 years, they haven't broken that ABI.
Re: Crux Linux!
Posted: Sat Feb 28, 2026 7:08 am
by Zema Bus
That's pretty good!

Re: Crux Linux!
Posted: Thu Mar 12, 2026 10:00 am
by Grogan
... and now I have my RBDoom3BFG. I compiled it on Arch though, because it's a big pain in the ass with build deps now (that I mostly already have on Arch), needing dxc (directx shader compiler) for the build, and now this Intel Implicit SIMD Program Compiler (ispc) which plugs into LLVM and needs spirv-llvm-translator. All for a 2 minute compile lol
On Crux, to run the game, the only dependencies I needed to install were SDL 2.0, and openal. Besides that, it's just vulkan (and the usual dependencies of glibc, libstdc++, libgcc_s)
Works great, the latest from github. Well, so far, anyway. It's probably pretty stable by now.
P.S. Definitely some bugs fixed. There was a mirror in a washroom, near the beginning in Mars City where if I looked in it, the game would instantly crash. Now I know what was different about that mirror, it turns to red film grain effect, and it shows your face kind of melting into a demonic visage. That probably means some other red demonic transitions in the second DLC campaign ("The Lost MIssion") won't crash now.