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. > 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.) Bruno
