[Solved] – Weird failure in GNU coreutils pkg.

Forum Forums News Sid Upgraders [Solved] – Weird failure in GNU coreutils pkg.

  • This topic has 1 reply, 1 voice, and was last updated Aug 4-3:43 pm by wildstar84.
Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #113402
    Member
    wildstar84

      I run rolling-testing, not sid, but decided to post this here, as it may be in sid as well due to the recentness of Debian’s recent version-“shift” (testing:=trixie, sid:=?). I encountered the nastiest issue I’ve ever run into in upgrading antiX today: After sucessfully updating everything over the last few days, particularly by backup box to latest trixie repositories/stuff, everything seemed to be working and testing well so I updated gcc from 12 to 13, and successfully switched from elogind to seatd. I don’t compile software every day (it’s been over a month), but when I needed to rebuild something (after a bunch of new Qt, ffmpeg, and some Glib/GTK libraries updated). This involves using the normally innocuous “./configure” as step 1. This time it CRASHED and BURNED spewing tons of “*** stack smashing detected *** … Aborted expr a : ‘\(a\)'” msgs. This was the case on BOTH my production AND backup boxes! I tried ./configure on (safe copies of) a cpl. other programs I’ve compiled, same s81t)! I tried reinstalling all the recent gcc and shell pkgs affected by the update, and even booted up with an older kernel (from >1month ago) to no avail. I dug into the configure script (Google says this msg. comes from buffer-overruns in C pgms, but this is a simple BASH script) and discovered that it calls “expr” in numerous places embedded in shel hyroglyphics. Sure enough expr is a C executable part of the GNU coreutils. Invoking it with no args or “–help” or “–version” was enough to get it to “smash stacks”! I saw and installed a “rust” vsn of these utils “rust-core-utils” and it’s vsn. WORKED! Still not the best workaround (imo), so I decided to look at the source, downloaded it, and (using the rust vsn. of “expr” (now symlinked w/the other one renamed “expr.bad”) I was able to build the regular C-vsn and replace the rust one with the one I built (both the package and source are v9.1-1 and my built one (w/simple ./configure;make & no special CFLAGS) seems to work great! I put it in /usr/local/bin; uninstalled the rust pkg. & symlinked /usr/bin/expr to my /usr/local/bin/expr for now. Has anyone else encountered this? You don’t have to run a configure script, just do:

      
      expr --version
      

      I still haven’t a clue why this has happened on BOTH my antiX boxes. My guess is either I got a bad download or someone at Debian built it for gcc-12 but should be for gcc-13 or a multiarch build w/wrong CFLAGS, perhaps?

      So, if anyone else runs into this, this workaround should work until perhaps next coreutils release – note, so far it’s only the “expr” binary (expr.c) that I’ve had any issue with and the only one I “installed”.

      #113585
      Member
      wildstar84

        Ok, guess no one else has run into this, good! Anyway, after updating my remaining antiX box (my router) today carefully, one step at a time starting with the least suspicious packages (in my guesstimation) and progressing from there, I’m convinced that it is the upgrade to packages “cpp” and “gcc” (both from v4:12.3.0-1 to 4:13.1.0-4) – “unLucky #13” (gcc-12 to gcc-13) that broke expr (fixed after manually recompiling coreutils myself w/gcc-13). I’m basing this assumption on the fact that everything there is now upgraded to what’s on my other boxen (EXCEPT these 2 pkgs. which I’m holding back for now – I don’t compile things on the router anyway and the latest Liquorix kernel upgrade doesn’t require it), and expr there is still working fine, so stickin’ w/gcc-12 there for now (as it is a irreversable upgrade). Yet another reason I remain a dist-upgrade “heratic”! 😉

      Viewing 2 posts - 1 through 2 (of 2 total)
      • You must be logged in to reply to this topic.