I've brought a variant of this issue to the libc-alpha and libstdc++ lists:

C23 addition of once_flag to <stdlib.h>
<https://inbox.sourceware.org/libstdc++/lhu1pmax8ix.fsf@oldenburg.str.redhat.com/>

Thanks, but is there a quick work-around we can apply while this is getting discussed?

(In reply to Dominik 'Rathann' Mierzejewski from comment #2)
> Thanks, but is there a quick work-around we can apply while this is getting
> discussed?

Only the very ugly

#define once_flag once_flag_disabled
#include <stdlib.h>
#undef once_flag_disabled

Or perhaps:

#define __once_flag_defined 1
#include <stdlib.h>

If this is a blocker for you, we can revert the change in Fedora rawhide.

Well, it is causing FTBFS to at least the three packages I added as blocker here.

(In reply to Dominik 'Rathann' Mierzejewski from comment #4)
> Well, it is causing FTBFS to at least the three packages I added as blocker
> here.

But does it block you from shipping an important update or similar?

Blocks, no. Causes issues, yes:

We have a big FFmpeg-related update with SONAME bump. I've submitted it,
because the risk of conflicts with other updates has been increasing daily.
That means those 3 packages (and 1 dependent) will start failing to install,
because they couldn't be rebuilt against the new FFmpeg (or at all).

These are leaf packages, so the impact is not huge, but OBS Studio is one
of the packages and it's pretty high profile.

Here's a build with a partial revert (for C++), as discussed upstream: https://koji.fedoraproject.org/koji/buildinfo?buildID=2857830

This partial revert has received upstream review and aligns with future C++ standard directions, but I want to give it a bit more time in case there are objections.

So I rediscovered these, heh. I've filed https://github.com/obsproject/obs-studio/issues/12808 for obs-studio. baresip builds with a tweak - https://src.fedoraproject.org/rpms/baresip/c/6dcf7d8ab40a1b7264e17e0df0e3abc2e6543017?branch=rawhide . I'm surprised libre fails, I'd expect it not to have the problem as it should use the C11 threading path; unfortunately the logs have expired. I'll have to do a scratch build to see what happens, I guess.

For libre, it seems my diagnosis was slightly wrong - it looks like libre's attempt to set HAVE_THREADS was just broken. Upstream reckons https://github.com/baresip/re/pull/1466 should fix it. Wasn't able to test yet because all builds currently are failing due to https://pagure.io/fedora-infrastructure/issue/12906 .

Adam, all the C++ ambiguity issues should go away with further upstream changes. We just can't get a new glibc build into buildroot because of infrastructure issues that impact testing.

This fix does not address issues with C sources. This is a separate discussion upstream (not yet started).

(In reply to Adam Williamson from comment #9)
> For libre, it seems my diagnosis was slightly wrong - it looks like libre's
> attempt to set HAVE_THREADS was just broken. Upstream reckons
> https://github.com/baresip/re/pull/1466 should fix it. Wasn't able to test
> yet because all builds currently are failing due to
> https://pagure.io/fedora-infrastructure/issue/12906 .

I've just tested with glibc-2.42.9000-10.fc44, but libre still fails even with that upstream patch applied:
...
In file included from /builddir/build/BUILD/libre-4.1.0-build/re-4.1.0/src/mem/mem.c:15:
/builddir/build/BUILD/libre-4.1.0-build/re-4.1.0/include/re_thread.h:45:9: warning: ‘ONCE_FLAG_INIT’ redefined
   45 | #define ONCE_FLAG_INIT PTHREAD_ONCE_INIT
      |         ^~~~~~~~~~~~~~
In file included from /usr/include/stdlib.h:1163,
                 from /builddir/build/BUILD/libre-4.1.0-build/re-4.1.0/src/mem/mem.c:7:
/usr/include/bits/types/once_flag.h:25:9: note: this is the location of the previous definition
   25 | #define ONCE_FLAG_INIT __ONCE_FLAG_INIT
      |         ^~~~~~~~~~~~~~
/builddir/build/BUILD/libre-4.1.0-build/re-4.1.0/include/re_thread.h:46:24: error: conflicting types for ‘once_flag’; have ‘pthread_once_t’ {aka ‘int’}
   46 | typedef pthread_once_t once_flag;
      |                        ^~~~~~~~~
/usr/include/bits/types/once_flag.h:24:21: note: previous declaration of ‘once_flag’ with type ‘once_flag’
   24 | typedef __once_flag once_flag;
      |                     ^~~~~~~~~
/builddir/build/BUILD/libre-4.1.0-build/re-4.1.0/include/re_thread.h:132:6: error: conflicting types for ‘call_once’; have ‘void(int *, void (*)(void))’
  132 | void call_once(once_flag *flag, void (*func)(void));
      |      ^~~~~~~~~
/usr/include/stdlib.h:1167:13: note: previous declaration of ‘call_once’ with type ‘void(once_flag *, void (*)(void))’
 1167 | extern void call_once (once_flag *__flag, void (*__func)(void));
      |             ^~~~~~~~~
...

(In reply to Florian Weimer from comment #3)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #2)
> > Thanks, but is there a quick work-around we can apply while this is getting
> > discussed?
> 
> Only the very ugly
> 
> #define once_flag once_flag_disabled
> #include <stdlib.h>
> #undef once_flag_disabled
> 
> Or perhaps:
> 
> #define __once_flag_defined 1
> #include <stdlib.h>

Neither of these helps with libre.

Florian, it should be fine to just waive the failed test for https://bodhi.fedoraproject.org/updates/FEDORA-2025-bfba5b5714 . The only required test that failed is baseos-qe.koji-build.scratch-build.validation , and it's clear from the logs that it actually worked, just ran into an infra issue at the end. That's a perfect candidate for waiving. Bonk the "Waive Test Results" button over on the right.

https://github.com/baresip/re/pull/1466 fixes libre, I've just confirmed that. I'll commit that, but I don't think we actually need a build of it at present, right?

well, hmm, maybe we should build it that way to make sure it's using the right threading implementation, then drop the hack in baresip and rebuild baresip against it, to make sure everything is consistent...

(In reply to Adam Williamson from comment #13)
> Florian, it should be fine to just waive the failed test for
> https://bodhi.fedoraproject.org/updates/FEDORA-2025-bfba5b5714 . The only
> required test that failed is baseos-qe.koji-build.scratch-build.validation ,
> and it's clear from the logs that it actually worked, just ran into an infra
> issue at the end. That's a perfect candidate for waiving. Bonk the "Waive
> Test Results" button over on the right.

Thanks, I had not looked that most recent results admittedly. I assumed they would be bad because koji watch-task (run locally) kept failing with 502 errors while I was preparing the build to test. Now waived.

(In reply to Dominik 'Rathann' Mierzejewski from comment #11)
> (In reply to Adam Williamson from comment #9)
> > For libre, it seems my diagnosis was slightly wrong - it looks like libre's
> > attempt to set HAVE_THREADS was just broken. Upstream reckons
> > https://github.com/baresip/re/pull/1466 should fix it. Wasn't able to test
> > yet because all builds currently are failing due to
> > https://pagure.io/fedora-infrastructure/issue/12906 .
> 
> I've just tested with glibc-2.42.9000-10.fc44, but libre still fails even
> with that upstream patch applied:

Scratch that, the build actually succeeds. I was applying the wrong patch to libre.

In other good news, obs-studio now succeeds (with that glibc in buildroot, tested locally in mock).

So, the C++ revert is stable now. Do we want to keep this open for any possible further changes?

libre and baresip were 'fixed' by fixing their thread detection thingy so they build on their C11 flags path instead of their pthread path, but I'm not sufficiently versed in all this stuff to know if we should still be worried about there potentially being problems for other C builds.

(In reply to Adam Williamson from comment #18)
> So, the C++ revert is stable now. Do we want to keep this open for any
> possible further changes?

Let's keep it open for a bit, as a reminder to myself that I need to raise the _GNU_SOURCE scope matter with glibc upstream.

icecat-140.5.0 is still failing with glibc-2.42.9000-10.fc44: https://koji.fedoraproject.org/koji/taskinfo?taskID=138861117

The failure there doesn't look like anything to do with glibc:

+ cp -p /usr/share/bookmarks/default-bookmarks.html objdir/dist/bin/browser/chrome/en-US/locale/browser/bookmarks.html
cp: cannot create regular file 'objdir/dist/bin/browser/chrome/en-US/locale/browser/bookmarks.html': No such file or directory

oh, never mind, there *is* a once_flag thing too. I guess it just causes the build to short-circuit rather than fail, and that's why we wind up trying to copy a non-existent file.

 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from src/compiler/glsl/glcpp/glcpp-parse.y:32:
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/src/mesa/main/mtypes.h:39:
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/include/c11/threads.h:66:
 1:35.16 [glslopt 0.1.11] cargo:warning=glsl-optimizer/include/c11/threads_posix.h:54:9: warning: 'ONCE_FLAG_INIT' macro redefined [-Wmacro-redefined]
 1:35.16 [glslopt 0.1.11] cargo:warning=   54 | #define ONCE_FLAG_INIT PTHREAD_ONCE_INIT
 1:35.16 [glslopt 0.1.11] cargo:warning=      |         ^
 1:35.16 [glslopt 0.1.11] cargo:warning=/usr/include/bits/types/once_flag.h:25:9: note: previous definition is here
 1:35.16 [glslopt 0.1.11] cargo:warning=   25 | #define ONCE_FLAG_INIT __ONCE_FLAG_INIT
 1:35.16 [glslopt 0.1.11] cargo:warning=      |         ^
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from src/compiler/glsl/glcpp/glcpp-parse.y:32:
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/src/mesa/main/mtypes.h:39:
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/include/c11/threads.h:66:
 1:35.16 [glslopt 0.1.11] cargo:warning=glsl-optimizer/include/c11/threads_posix.h:69:25: error: typedef redefinition with different types ('pthread_once_t' (aka 'int') vs '__once_flag')
 1:35.16 [glslopt 0.1.11] cargo:warning=   69 | typedef pthread_once_t  once_flag;
 1:35.16 [glslopt 0.1.11] cargo:warning=      |                         ^
 1:35.16 [glslopt 0.1.11] cargo:warning=/usr/include/bits/types/once_flag.h:24:21: note: previous definition is here
 1:35.16 [glslopt 0.1.11] cargo:warning=   24 | typedef __once_flag once_flag;
 1:35.16 [glslopt 0.1.11] cargo:warning=      |                     ^
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from src/compiler/glsl/glcpp/glcpp-parse.y:32:
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/src/mesa/main/mtypes.h:39:
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/include/c11/threads.h:66:
 1:35.16 [glslopt 0.1.11] cargo:warning=glsl-optimizer/include/c11/threads_posix.h:94:1: error: static declaration of 'call_once' follows non-static declaration
 1:35.16 [glslopt 0.1.11] cargo:warning=   94 | call_once(once_flag *flag, void (*func)(void))
 1:35.16 [glslopt 0.1.11] cargo:warning=      | ^
 1:35.16 [glslopt 0.1.11] cargo:warning=/usr/include/stdlib.h:1167:13: note: previous declaration is here
 1:35.16 [glslopt 0.1.11] cargo:warning= 1167 | extern void call_once (once_flag *__flag, void (*__func)(void));
 1:35.16 [glslopt 0.1.11] cargo:warning=      |             ^
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from src/compiler/glsl/glcpp/glcpp-parse.y:32:
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/src/mesa/main/mtypes.h:39:
 1:35.16 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/include/c11/threads.h:66:
 1:35.16 [glslopt 0.1.11] cargo:warning=glsl-optimizer/include/c11/threads_posix.h:96:18: warning: incompatible pointer types passing 'once_flag *' (aka '__once_flag *') to parameter of type 'pthread_once_t *' (aka 'int *') [-Wincompatible-pointer-types]
 1:35.16 [glslopt 0.1.11] cargo:warning=   96 |     pthread_once(flag, func);
 1:35.16 [glslopt 0.1.11] cargo:warning=      |                  ^~~~
 1:35.16 [glslopt 0.1.11] cargo:warning=/usr/include/pthread.h:509:42: note: passing argument to parameter '__once_control' here
 1:35.16 [glslopt 0.1.11] cargo:warning=  509 | extern int pthread_once (pthread_once_t *__once_control,
 1:35.16 [glslopt 0.1.11] cargo:warning=      |                                          ^

I started an upstream discussion about source-level compatibility:

Refining _DEFAULT_SOURCE and _GNU_SOURCE
<https://inbox.sourceware.org/libc-alpha/lhuo6on8aav.fsf@oldenburg.str.redhat.com/>

I just noticed this also seems to be causing Firefox build failures, e.g.:

1:51.56 [glslopt 0.1.11] error occurred in cc-rs: command did not execute successfully (status code exit status: 1): LC_ALL="C" "/usr/bin/gcc" "-O1" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "glsl-optimizer/include" "-I" "glsl-optimizer/src/mesa" "-I" "glsl-optimizer/src/mapi" "-I" "glsl-optimizer/src/compiler" "-I" "glsl-optimizer/src/compiler/glsl" "-I" "glsl-optimizer/src/gallium/auxiliary" "-I" "glsl-optimizer/src/gallium/include" "-I" "glsl-optimizer/src" "-I" "glsl-optimizer/src/util" "-D__STDC_FORMAT_MACROS" "-D_GNU_SOURCE" "-DHAVE_ENDIAN_H" "-DHAVE_PTHREAD" "-DHAVE_TIMESPEC_GET" "-DMOZ_INCLUDE_MOZALLOC_H" "-Dmozilla_throw_gcc_h" "-O2" "-fexceptions" "-g" "-grecord-gcc-switches" "-pipe" "-Wall" "-Werror=format-security" "-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3" "-Wp,-D_GLIBCXX_ASSERTIONS" "-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" "-fstack-protector-strong" "-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1" "-m64" "-march=x86-64" "-mtune=generic" "-fasynchronous-unwind-tables" "-fstack-clash-protection" "-fcf-protection" "-mtls-dialect=gnu2" "-fno-omit-frame-pointer" "-mno-omit-leaf-frame-pointer" "-std=gnu17" "-I/builddir/build/BUILD/firefox-146.0-build/firefox-146.0/objdir/instrumented/dist/system_wrappers" "-include" "/builddir/build/BUILD/firefox-146.0-build/firefox-146.0/config/gcc_hidden.h" "-U_FORTIFY_SOURCE" "-D_FORTIFY_SOURCE=2" "-fstack-protector-strong" "-fstrict-flex-arrays=1" "-DNDEBUG=1" "-DTRIMMED=1" "-I/builddir/build/BUILD/firefox-146.0-build/firefox-146.0/objdir/instrumented/dist/include" "-I/usr/include/nspr4" "-I/usr/include/nss3" "-I/usr/include/nspr4" "-I/builddir/build/BUILD/firefox-146.0-build/firefox-146.0/objdir/instrumented/dist/include/nss" "-DWITH_GZFILEOP" "-I/usr/include/pixman-1" "-DMOZILLA_CLIENT" "-include" "/builddir/build/BUILD/firefox-146.0-build/firefox-146.0/objdir/instrumented/mozilla-config.h" "-pthread" "-ffunction-sections" "-fdata-sections" "-fno-math-errno" "-pipe" "-fPIC" "-O2" "-g1" "-grecord-gcc-switches" "-pipe" "-Wno-complain-wrong-lang" "-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3" "-Wp,-D_GLIBCXX_ASSERTIONS" "-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" "-fstack-protector-strong" "-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1" "-m64" "-march=x86-64" "-mtune=generic" "-fasynchronous-unwind-tables" "-fstack-clash-protection" "-fcf-protection" "-mtls-dialect=gnu2" "-fno-omit-frame-pointer" "-mno-omit-leaf-frame-pointer" "-fpermissive" "-DNSS_PKCS11_3_0_STRICT" "-O3" "-fomit-frame-pointer" "-funwind-tables" "-Wno-error=deprecated" "-Wno-error=maybe-uninitialized" "-Wno-error=deprecated-declarations" "-Wno-error=array-bounds" "-Wno-error=free-nonheap-object" "-Wno-multistatement-macros" "-Wno-error=class-memaccess" "-Wno-psabi" "-Wno-error=builtin-macro-redefined" "-fno-strict-aliasing" "-ffp-contract=off" "-DNS_FREE_PERMANENT_DATA=1" "-DMOZILLA_CONFIG_H" "-o" "/builddir/build/BUILD/firefox-146.0-build/firefox-146.0/objdir/instrumented/release/build/glslopt-3f9ee61080858b78/out/ecc5ce2ee3e1d37b-pp.o" "-c" "glsl-optimizer/src/compiler/glsl/glcpp/pp.c"
 1:51.56 [glslopt 0.1.11]
 1:51.56 [glslopt 0.1.11]
 1:51.56 warning: glslopt.11: In file included from glsl-optimizer/include/c11/threads.h:66,
 1:51.56 warning: glslopt.11:                  from glsl-optimizer/src/mesa/main/mtypes.h:39,
 1:51.56 warning: glslopt.11:                  from src/compiler/glsl/glcpp/glcpp-parse.y:32:
 1:51.56 warning: glslopt.11: glsl-optimizer/include/c11/threads_posix.h:54:9: warning: 'ONCE_FLAG_INIT' redefined
 1:51.56 warning: glslopt.11:    54 | #define ONCE_FLAG_INIT PTHREAD_ONCE_INIT
 1:51.56 warning: glslopt.11:       |         ^~~~~~~~~~~~~~
 1:51.56 warning: glslopt.11: In file included from /usr/include/stdlib.h:1191,
 1:51.56 warning: glslopt.11:                  from /builddir/build/BUILD/firefox-146.0-build/firefox-146.0/objdir/instrumented/dist/system_wrappers/stdlib.h:3,
 1:51.56 warning: glslopt.11:                  from src/compiler/glsl/glcpp/glcpp-parse.y:26:
 1:51.56 warning: glslopt.11: /usr/include/bits/types/once_flag.h:25:9: note: this is the location of the previous definition
 1:51.56 warning: glslopt.11:    25 | #define ONCE_FLAG_INIT __ONCE_FLAG_INIT
 1:51.56 warning: glslopt.11:       |         ^~~~~~~~~~~~~~
 1:51.56 warning: glslopt.11: glsl-optimizer/include/c11/threads_posix.h:69:25: error: conflicting types for 'once_flag'; have 'pthread_once_t' {aka 'int'}
 1:51.56 warning: glslopt.11:    69 | typedef pthread_once_t  once_flag;
 1:51.56 warning: glslopt.11:       |                         ^~~~~~~~~
 1:51.56 warning: glslopt.11: /usr/include/bits/types/once_flag.h:24:21: note: previous declaration of 'once_flag' with type 'once_flag'
 1:51.56 warning: glslopt.11:    24 | typedef __once_flag once_flag;
 1:51.56 warning: glslopt.11:       |                     ^~~~~~~~~
 1:51.56 warning: glslopt.11: glsl-optimizer/include/c11/threads_posix.h:94:1: error: conflicting types for 'call_once'; have 'void(int *, void (*)(void))'
 1:51.56 warning: glslopt.11:    94 | call_once(once_flag *flag, void (*func)(void))
 1:51.56 warning: glslopt.11:       | ^~~~~~~~~
 1:51.56 warning: glslopt.11: /usr/include/stdlib.h:1195:13: note: previous declaration of 'call_once' with type 'void(once_flag *, void (*)(void))'
 1:51.56 warning: glslopt.11:  1195 | extern void call_once (once_flag *__flag, void (*__func)(void));
 1:51.56 warning: glslopt.11:       |             ^~~~~~~~~

There are multiple errors like that, that's just the first one. All Firefox builds for Rawhide since November 3 have failed like this. That extract is from the most recent attempt, https://koji.fedoraproject.org/koji/buildinfo?buildID=2876236 . CCing mstransky .

Yes, Firefox is broken now, thunderbird too.

What's the status of this change? Do we need to update Firefox/Thunderbird for it or can it be reverted? AFAIK (from my limited knowledge) this change affects rust crates so we'd need to hack/regenerate them somehow inside Firefox sources (direct patch doesn't work as it calc checksum).

(In reply to Martin Stransky from comment #26)
> What's the status of this change? Do we need to update Firefox/Thunderbird
> for it or can it be reverted? AFAIK (from my limited knowledge) this change
> affects rust crates so we'd need to hack/regenerate them somehow inside
> Firefox sources (direct patch doesn't work as it calc checksum).

I mean can we expect also 'C' change or do we need to update/regenerate the crates?
Also it's a bit problematic upstream - I don't think upstream will accept this change any time soon - so we'd need to carry on local patches.