Crux Linux!

The place to discuss Linux and Unix Operating Systems
Forum rules
Behave
User avatar
Grogan
Your Host
Posts: 3211
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: Crux Linux!

Post 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 :-)
User avatar
Zema Bus
Your Co-Host
Posts: 1955
Joined: Sun Feb 04, 2024 1:25 am
Location: Arizona

Re: Crux Linux!

Post by Zema Bus »

:thumbsup:
User avatar
Grogan
Your Host
Posts: 3211
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: Crux Linux!

Post 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.
User avatar
Zema Bus
Your Co-Host
Posts: 1955
Joined: Sun Feb 04, 2024 1:25 am
Location: Arizona

Re: Crux Linux!

Post 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!
User avatar
Grogan
Your Host
Posts: 3211
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: Crux Linux!

Post 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.
User avatar
mlangdn
Master of Ceremonies
Posts: 110
Joined: Thu Apr 07, 2022 11:28 pm
Location: Western Kentucky

Re: Crux Linux!

Post 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/
User avatar
Zema Bus
Your Co-Host
Posts: 1955
Joined: Sun Feb 04, 2024 1:25 am
Location: Arizona

Re: Crux Linux!

Post 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.
User avatar
Grogan
Your Host
Posts: 3211
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: Crux Linux!

Post 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.
User avatar
Grogan
Your Host
Posts: 3211
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: Crux Linux!

Post 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 :lol:

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}
}
User avatar
Grogan
Your Host
Posts: 3211
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: Crux Linux!

Post 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.
User avatar
Zema Bus
Your Co-Host
Posts: 1955
Joined: Sun Feb 04, 2024 1:25 am
Location: Arizona

Re: Crux Linux!

Post by Zema Bus »

That's pretty good! :)
User avatar
Grogan
Your Host
Posts: 3211
Joined: Sat Aug 21, 2021 10:04 am
Location: Ontario, Canada

Re: Crux Linux!

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