On 30/07/26 12:13, Bruno Haible wrote:
> Adhemerval Zanella Netto wrote:
>>> People therefore typically prefer approach (L) for C libraries, as can be
>>> seen through the widespread use of libffi in the Free Software ecosystem.
>>
>> But this is not strictly correct
>
> Yes, approach (L) is not "strictly correct" to the letter of ISO C and POSIX.
> But all the packages that depend on libffi do it (because a binding via libffi
> is much smaller than a binding via SWIG). And there are many of them:
>
> $ apt rdepends libffi8
> libffi8
> Reverse Depends:
> Depends: libffi-dev (= 3.5.2-4)
> Depends: firefox-esr (>= 3.4)
> Depends: php8.5-common (>= 3.4)
> Depends: libruby3.3 (>= 3.4)
> Depends: libpython3.14-stdlib (>= 3.4)
> Depends: libpython3.14-dbg (>= 3.4)
> Depends: zig0.14
> Depends: yosys (>= 3.4)
> Depends: yi (>= 3.4)
> Depends: yesod (>= 3.4)
> Depends: yabasic (>= 3.4)
> Depends: xmonad (>= 3.4)
> Depends: xmobar (>= 3.4)
> Depends: uuagc (>= 3.4)
> Depends: unlambda (>= 3.4)
> Depends: termonad (>= 3.4)
> Depends: tasty-discover (>= 3.4)
> Depends: stylish-haskell (>= 3.4)
> Depends: skylighting (>= 3.4)
> Depends: shelltestrunner (>= 3.4)
> Depends: shellcheck (>= 3.4)
> Depends: raincat (>= 3.4)
> Depends: propellor (>= 3.4)
> Depends: ppsh (>= 3.4)
> Depends: pkg-haskell-tools (>= 3.4)
> Depends: pid1 (>= 3.4)
> Depends: picolisp (>= 3.4)
> Depends: phybin (>= 3.4)
> Depends: patat (>= 3.4)
> Depends: pandoc-citeproc-preamble (>= 3.4)
> Depends: pandoc (>= 3.4)
> Depends: ormolu (>= 3.4)
> Depends: ogma (>= 3.4)
> Depends: newlisp (>= 3.4)
> Depends: mueval (>= 3.4)
> Depends: moarvm (>= 3.4)
> Depends: mighttpd2 (>= 3.4)
> Depends: micropython (>= 3.4)
> Depends: mediawiki2latex (>= 3.4)
> Depends: markdown-unlit (>= 3.4)
> Depends: macaulay2 (>= 3.4)
> Depends: lua-lgi (>= 3.4)
> Depends: libpolyml9 (>= 3.4)
> Depends: libomp5-17t64 (>= 3.4)
> Depends: libllvm22 (>= 3.4)
> Depends: libllvm20 (>= 3.4)
> Depends: libllvm19 (>= 3.4)
> Depends: libllvm18 (>= 3.4)
> Depends: libllvm17t64 (>= 3.4)
> Depends: libllvm-rocm (>= 3.4)
> Depends: libjna-jni (>= 3.4)
> Depends: libjffi-jni (>= 3.4)
> Depends: libhyprwire3 (>= 3.4)
> Depends: libgnustep-base1.31 (>= 3.4)
> Depends: libglib2.0-tests (>= 3.4)
> Depends: libghc-wai-app-static-dev (>= 3.4)
> Depends: libghc-hjsmin-dev (>= 3.4)
> Depends: libghc-hakyll-dev (>= 3.4)
> Depends: libghc-ghc-events-dev (>= 3.4)
> Depends: libffi-platypus-perl (>= 3.4)
> Depends: libecl24.5 (>= 3.4)
> Depends: libctypes-ocaml (>= 3.4)
> Depends: libcriterion3 (>= 3.4)
> Depends: libcjs0 (>= 3.4)
> Depends: lambdahack (>= 3.4)
> Depends: lambdabot (>= 3.4)
> Depends: kickoff (>= 3.4)
> Depends: jmacro (>= 3.4)
> Depends: ikarus (>= 3.4)
> Depends: hspec-discover (>= 3.4)
> Depends: hscolour (>= 3.4)
> Depends: hsbrainfuck (>= 3.4)
> Depends: hpack (>= 3.4)
> Depends: hopenpgp-tools (>= 3.4)
> Depends: hoogle (>= 3.4)
> Depends: hlint (>= 3.4)
> Depends: hledger-web (>= 3.4)
> Depends: hledger-ui (>= 3.4)
> Depends: hledger-interest (>= 3.4)
> Depends: hledger (>= 3.4)
> Depends: hedgewars (>= 3.4)
> Depends: hdav (>= 3.4)
> Depends: haxml (>= 3.4)
> Depends: hasktags (>= 3.4)
> Depends: haskell-zip-utils (>= 3.4)
> Depends: haskell-zip-stream-utils (>= 3.4)
> Depends: haskell-what4-utils (>= 3.4)
> Depends: haskell-vty-unix-utils (>= 3.4)
> Depends: haskell-status-notifier-item-utils (>= 3.4)
> Depends: haskell-stack (>= 3.4)
> Depends: haskell-sdl2-mixer-utils (>= 3.4)
> Depends: haskell-sdl2-image-utils (>= 3.4)
> Depends: haskell-misfortune (>= 3.4)
> Depends: haskell-lazy-csv-utils (>= 3.4)
> Depends: haskell-gtk-sni-tray-utils (>= 3.4)
> Depends: haskell-groom-utils (>= 3.4)
> Depends: haskell-debian-utils (>= 3.4)
> Depends: haskell-dbus-hslogger-utils (>= 3.4)
> Depends: haskell-clash-lib-utils (>= 3.4)
> Depends: haskell-clash-ghc-utils (>= 3.4)
> Depends: haskell-aeson-diff-utils (>= 3.4)
> Depends: happy (>= 3.4)
> Depends: hadrian (>= 3.4)
> Depends: hackage-tracker (>= 3.4)
> Depends: guile-3.0-libs (>= 3.4)
> Depends: guile-2.2-libs (>= 3.4)
> Depends: gtk2hs-buildtools (>= 3.4)
> Depends: glirc (>= 3.4)
> Depends: gitit (>= 3.4)
> Depends: git-repair (>= 3.4)
> Depends: git-mediate (>= 3.4)
> Depends: git-annex (>= 3.4)
> Depends: ghkl (>= 3.4)
> Depends: ghc (>= 3.4)
> Depends: gforth-lib (>= 3.4)
> Depends: ganeti-htools-3.1 (>= 3.4)
> Depends: ganeti-haskell-3.1 (>= 3.4)
> Depends: gambas3-runtime (>= 3.4)
> Depends: g-golf (>= 3.4)
> Depends: futhark (>= 3.4)
> Depends: elm-compiler (>= 3.4)
> Depends: doctest (>= 3.4)
> Depends: dhall (>= 3.4)
> Depends: debug-me (>= 3.4)
> Depends: datapacker (>= 3.4)
> Depends: darcs (>= 3.4)
> Depends: crystal (>= 3.4)
> Depends: cpphs (>= 3.4)
> Depends: cabal-install (>= 3.4)
> Depends: cabal-debian (>= 3.4)
> Depends: c2hs (>= 3.4)
> Depends: bnfc (>= 3.4)
> Depends: allure (>= 3.4)
> Depends: alex (>= 3.4)
> Depends: agda-bin (>= 3.4)
> Depends: aeson-pretty (>= 3.4)
> Depends: ruby-ffi (>= 3.4)
> Depends: python3-gi (>= 3.4)
> Depends: python3-cffi-backend (>= 3.4)
> Depends: php8.5-common (>= 3.4)
> Depends: p11-kit-modules (>= 3.4)
> Depends: libwayland-server0 (>= 3.4)
> Depends: libwayland-client0 (>= 3.4)
> Depends: libruby3.3 (>= 3.4)
> Depends: libpython3.14-stdlib (>= 3.4)
> Depends: libpython3.14-dbg (>= 3.4)
> Depends: libp11-kit0 (>= 3.4)
> Depends: libllvm21 (>= 3.4)
> Depends: libglib2.0-0t64 (>= 3.4)
> Depends: libglib-object-introspection-perl (>= 3.4)
> Depends: libgjs0 (>= 3.4)
> Depends: libgirepository-2.0-0 (>= 3.4)
> Depends: libgirepository-1.0-1 (>= 3.4)
> Depends: girepository-tools (>= 3.4)
> Depends: gobject-introspection (>= 3.4)
>
> glibc is part of an ecosystem of packages of which many are not "strictly
> correct"
> according to ISO C and POSIX, and a number of them are using libffi for
> glibc bindings.
I understand that Hyrum's Law hit us again, it is just that is unfortunate that
we now have another undocumented constraint that would require us to add more
complexity for newer symbols and testing, and that is technically subpar.
>
>> and even for some interface we do not fully
>> support it. For instance, for LFS or 64 time-t support configure will
>> potentially
>> check the wrong symbol used during binary linking, which is surprising at
>> least.
>
> Yes. But there are good reasons for these: LFS and Y2038 safety.
> Whereas for posix_spawn_file_actions_addchdir, I don't see a good, strong
> reason.
>
>> I tend to agree with Andreas here that our exported interfaces are tied to
>> the exported headers and trying to used them separately is UB and adds an
>> extra constraint for development and testing.
>
> I vote for glibc to add this extra constraint during development and testing.
> Rationale:
> As said above, glibc bindings of type (L) exist in several packages.
> And AC_CHECK_FUNCS is used in many packages as well.
> glibc is embedded in an ecosystem of packages.
>
>> I think for this case this ship has already sailed. We can fixed
>> for 2.45, but our current policy is to not introduce new symbols on release
>> branches. It would be doable, but I really want to avoid it.
>
> I understand; this would be an iffy thing to do.
>
> So, your preference would be that new releases of
> GNU m4
> GNU gettext
> GNU bison
> GNU wget2
> get made, before distros start rolling out glibc-2.44 at a large scale?
> (I don't see any other option for avoiding significant numbers of bug
> reports.)
I don't have a strong opinion, I am more inclined to add this new symbol on
2.44. There is the extra annoyance that a lot of consumers do not track the
release branch, but rather the release package; and I think it highly unlikely
we would release 2.44.1. Andreas might have a different opinion here.
It would be good to hear from other maintainers whether this would be
acceptable.
