The next GNU Tools Cauldron, taking place in Porto, Portugal, on September 26-28, 2025.
https://inbox.sourceware.org/gcc/87o6ubhn4j.fsf@oracle.com/
https://gcc.gnu.org/wiki/cauldron2025
https://gnu-tools-cauldron.org/
Some #Sourceware Project Leadership Committee members and @conservancy staff should also be there.
#GCC #GDB #binutils #CGEN #DejaGnu #newlib #glibc #poke #libabigail #elfutils
When researching for one of my last articles, I noticed a speed difference between RHEL7 and RHEL10. I used these 2, but the observed speciality can also be seen on (all?) other distros.
Got to the ground of it, might make a fun read for all involved with glibc and emulation :
https://blog.fluxcoil.net/posts/2025/06/the-riddle-of-rhel7-being-faster-than-rhel10/
#qemu #glibc #emulation
EDIT: graphics added to the article
@ULTROS_PROFESSIONAL @mos_8502 yeah. #GlibC randomly bricks shit at minor version updates.
Their response: "JuSt ReCoMpIlE!"
@mrmasterkeyboard @landley exactly that is literally the Problem with #native #Linux games:
@mrmasterkeyboard @landley My choice of @musl for @OS1337 is because I want my stuff to be statically linked and not every minor update to have the risk to brick shit, because #GlibC is notorious for that since the #GNU project are nonchalantly thinking "just recompile it" is a valid excuse.
I mean, we all 'loved' to live in a world where this wasn't the case but if I were to like deal with a vocoder for MELP, AMBE or TWELP I'm pretty shure I'd never ever be allowed to distribute it's source code, even for "clients exempted from the need to obtain licensing"...
@lmemsm basically the Idea behind it is to be a brutally simple #toybox + #musl / #linux distro that grew out of the necessity for me to actually think about #firmware for some projects.
Basically I want something that is so simple and auditable that it's practical to make it pass any #verification demands for #SecureTerminal|s in #CriticalInfrastructure and #Communications.
Not to mention a #GNUfree - #Linux distro is the way to go if I want that thing to not get bricked constantly by minor #GlibC-changes...
I hope that answers your question...
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
Reading through the code, and I'm not even sure that some of the PHP functions make sense!
PHP has a `crypt` function that takes a string and a salt. But the Wordpress code _and_ the in-page function are using the hashed password as the salt. Which makes no sense. How can you salt a password with the hashed password and get something that you can compare against?
Wait. There _is_ something in the PHP docs. Not well signposted. But apparently "salt" _is_ extracted from hashed values. Which is SO obvious from the parameter naming 🙄
Should say up-front "$salt is not actually the salt - it's a string containing the salt and other characters that's processed according to the chosen crypt algorithm"
*digs further*
Oh. It looks like that magic behaviour is ACTUALLY the fault of glibc2 😑 https://linux.die.net/man/3/crypt
(Not clear yet how it handles `$P$` not being one of its known prefixes 😐)
Solved! 🥳
This was a pretty "interesting" bug. Remember when I invented a way to implement #async / #await in #C, for jobs running on a threadpool. Back then I said it only works when completion of the task resumes execution on the *same* pool thread.
Trying to improve overall performance, I found the complex logic to identify the thread job to put on a pool thread a real deal-breaker. Just having one single MPMC queue with a single semaphore for all pool threads to wait on is a lot more efficient. But then, a job continued after an awaited task will resume on a "random" thread.
It theoretically works by making sure to restore the CORRECT context (the original one of the pool thread) every time after executing a job, whether partially (up to the next await) or completely.
Only it didn't, at least here on #FreeBSD, and I finally understood the reason for this was that I was using #TLS (thread-local storage) to find the context to restore.
Well, most architectures store a pointer to the current thread metadata in a register. #POSIX user #context #switching saves and restores registers. I found a source claiming that the #Linux (#glibc) implementation explicitly does NOT include the register holding a thread pointer. Obviously, #FreeBSD's implementation DOES include it. POSIX doesn't have to say anything about that.
In short, avoiding TLS accesses when running with a custom context solved the crash. 🤯
apt-listchanges: News
---------------------
#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:
GLIBC_TUNABLES=glibc.rtld.execstack=2 ./program
-- Aurelien Jarno <aurel32@debian.org> Sun, 13 Apr 2025 14:41:11 +0200
@MichaelRoss something I have been trying to look for is a #Linux #ls that isn't depending on #glibc or another #libc implementation, the reason is there was some malware that attached itself to glibc and prevented you to see the directories and files it used and also the process directory in /proc
Had you a ls that wasn't built with glibc, then all the files and directories would be listed.
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.
The getopt_long manual page contains this:
> Long option names may be abbreviated if the abbreviation is unique or is an
> exact match for some defined option.
But the uniqueness does not seem to be enforced. For
static struct option long_options[] = {
{"foo", no_argument, 0, 0 },
{"far", no_argument, 0, 0 },
{0, 0, 0, 0 }
};
and -f as an argument to my program, I get back that "foo" was matched. How can
I detect the collision?
⚠️ 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/
@cleverboi
Boi, I'm not knowledgeable about glibc, but I do use and like Pop!_Os, so I'm boosting your twt in an effort to secure you an answer.
I don't know your use case, so I have no clue why you'd be having this software issue with Pop!_Os!
Hope someone else can be of actual assistance.
#Linux #GLIBC #Pop!_Os #PopOs
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
Sourceware Survey 2025 Results
In the end we got 103 (!) responses with a nice mix of developers, users and maintainers from various hosted projects.
https://sourceware.org/survey-2025
#binutils #cygwin #dwarfstd #elfutils #gcc #gdb #glibc #libabigail #newlib #systemTap #valgrind #bzip2 #libffi #dwz #debugedit #gnupoke #bunsen #lvm2 #annobin #gnu-gabi #cgen #kawa #insight #pacme
#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
