Re: PR lib/59751: dlclose is not MT-safe depending on the libraries unloaded

On Saturday 18 Jul 2026, at 05:19, Taylor R Campbell wrote:
> That patch was hopelessly broken, sorry!  It just pushed a deeper
> underlying problem around.

No problem. When I thought myself about it I figured out this was
awfully complex. I'm rather happy that you started to work on this
right when I was starting to have my issues! (coincidence).

> Can you try updating ld.elf_so from HEAD and see if that makes a
> difference?

I tried with HEAD from today (20/07/2026, 21:00 CEST), rtld.c rev 1.228.
The good news is that this fixes the segfaults in my application, at
least as far as I can tell after just a quick testing.
So this is definitively an awesome progress.

Today, I also read messages in some mailing list complaining about
failed assertions, but I'm not sure wether your commits today were
related to this or not. So far I didn't had any regression with
e.g. firefox or emacs.

I tried to create a reproducer for my scenario inspired from yours,
but dit not succeed so far. For sure my application does not dlopen
things in constructors (it only dlclose in the dtors), and when moving
the dlopen in your test code from the constructor to a regular
function the issue disappear even with the old ld.elf_so.

To test, I only disabled DEBUG in the Makefile (the build was failing
with undefined symbols like xassert etc., as I only built ld.elf_so).
Also, I removed the lo, hi variables in tls.c as, without debug, -Werror
was complaining about set but unsued vars.

Are you confident with your changes ? (I mean should I revert
ld.elf_so to ~16/07/2026 to avoid any regression or do you prefer me
continuing to test this a bit?)

Anyway, thanks a lot for your efforts!
Anthony