One year to the day after my first #glibc commit is written, I am back at Arjun’s glibc clinic for round two! @devconf_cz

All I want is just a collection of #binutils, #GCC, #llvm+#clang, #glibc and #musl that are "free standing" / relocatable, which I can pack into a #squashfs image to carry around to my various development machines.

You'd think that for something as fundamental as compiler infrastructure with over 60 years of knowledge, the whole bootstrapping and bringup process would have been super streamlined, or at least mostly pain free by now.

Yeah, about that. IYKYK

Debian LTS contributors released 46 Debian LTS Advisories about security updates for various packages in April 2025.

These include critical security bug fixes for jetty9, zabbix and glibc and more. Also several LTS contributors prepared packages for the recent point release of current stable Debian 12, with many prepared in conjunction with related LTS updates of the same packages.

Read more about this in our monthly report for April here: https://www.freexian.com/blog/debian-lts-report-2025-04/

This work is funded by Freexian's Debian LTS offering.

Your organization too can sponsor the Debian LTS (https://www.freexian.com/lts/debian/) and join the esteemed list of sponsors in the monthly report.

Steam Will Stop Working on Outdated Linux Systems This August | Linuxiac

｢ According to a recent announcement, the Steam client will no longer run on any distribution with a GNU C Library (glibc) version older than 2.31 starting August 15, 2025.

Users who stay on an outdated toolchain will find not only Steam but also any purchased games unable to launch until the underlying operating system is upgraded ｣

https://linuxiac.com/steam-will-stop-working-on-outdated-linux-systems-this-august/

glibc (2.41-7) unstable; urgency=medium

Starting with glibc 2.41, shared libraries requiring an executable stack
cannot be dynamically loaded through the #dlopen mechanism from a binary that
does not require an executable stack. This change aims to improve security,
as the previous behavior was used as a vector for RCE (#CVE-2023-38408).
Attempting to do so will result in the following error:

cannot enable executable stack as shared object requires: Invalid argument

While most libraries generated in the past 20 years do not require an
executable stack, some third-party software still need this capability. Many
vendors have already updated their binaries to address this.

If you need to run a program that requires an executable stack through
dynamic loaded shared libraries, you can use the glibc.rtld.execstack
tunable:

Glibc6_TUNABLES=glibc.rtld.execstack=2 ./program

-- Aurelien Jarno <aurel32@debian.org> Sun, 13 Apr 2025 14:41:11 +0200

On August 15th, 2025, Steam will officially stop supporting Linux distributions with a version of glibc older than 2.31

https://friendica.world/display/84b6ef2b-3168-0736-1c9c-81e579514582

#tek 0.2.0 out now: https://codeberg.org/unspeaker/tek/releases/tag/0.2.0

it's buggy as hell, and about half the features i've showcased previously are disabled for now. but, more importantly, i've managed to build it as a single binary that you should be able to run on any #linux with #glibc and #jack... let me know what happens!

Today, I implemented the #async / #await pattern (as known from #csharp and meanwhile quite some other languages) ...

... in good old #C!

Well, at least sort of.

* It requires some standard library support, namely #POSIX user context switching with #getcontext and friends, which was deprecated in POSIX-1.2008. But it's still available on many systems, including #FreeBSD, #NetBSD, #Linux (with #glibc). It's NOT available e.g. on #OpenBSD, or Linux with some alternative libc.

* I can't do anything about the basic language syntax, so some boilerplate comes with using it.

* It has some overhead (room for extra stacks, even extra syscalls as getcontext unfortunately also always saves/restores the signal mask)

But then ... async/await in C!

Here are the docs:
https://zirias.github.io/poser/api/latest/class_p_s_c___async_task.html

I finally eliminated the need for a dedicated #thread controlling the pam helper #process in #swad.

The building block that was still missing from #poser was a way to await some async I/O task performed on the main thread from a worker thread. So I added a class to allow exactly that. The naive implementation just signals the main thread to carry out the requested task and then waits on a #semaphore for completion, which of course blocks the worker thread.

Turns out we can actually do better, reaching similar functionality like e.g. #async / #await in C#: Release the worker thread to do other jobs while waiting. The key to this is user context switching support like offered by #POSIX-1.2001 #getcontext and friends. Unfortunately it was deprecated in POSIX-1.2008 without an obvious replacement (the docs basically say "use threads", which doesn't work for my scenario), but still lots of systems provide it, e.g. #FreeBSD, #NetBSD, #Linux (with #glibc) ...

The posercore lib now offers both implementations, prefering to use user context switching if available. It comes at a price: Every thread job now needs its private stack space (I allocated 64kiB there for now), and of course the switching takes some time as well, but that's very likely better than leaving a task idle waiting. And there's a restriction, resuming must still happen on the same thread that called the "await", so if this thread is currently busy, we have to wait a little bit longer. I still think it's a very nice solution.

In any case, the code for the PAM credential checker module looks much cleaner now (the await "magic" happens on line 174):
https://github.com/Zirias/swad/blob/57eefe93cdad0df55ebede4bd877d22e7be1a7f8/src/bin/swad/cred/pamchecker.c

The #Maneage #reproducibility system for scientific research papers that starts from a minimal POSIX-like host OS does not yet build [1] the #GNUCLibrary = #GLibC . We have a draft implementation building glibc *after* #GCC [2]; and an alternative proposal arguing that building glibc *first* and gcc second would be more long-term sustainable [[1] comment18].

Should GLibC be built first? Why (or why not)?

[1] https://savannah.nongnu.org/task/?15390
[2] https://gitlab.com/maneage/project-dev/-/blob/glibc/reproduce/software/make/core-gnu.mk#L718