[MacPorts] #74109: glib2 @2.88.1_0+universal+x11 configure error

[MacPorts]

#74109: glib2 @2.88.1_0+universal+x11 configure error
----------------------+-------------------------
  Reporter:  murrayE  |      Owner:  mascguy
      Type:  defect   |     Status:  assigned
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.12.5
Resolution:           |   Keywords:  tahoe arm64
      Port:  glib2    |
----------------------+-------------------------

Comment (by reneeotten):

 okay, Claude says this after it looked at the {{{glib2-compile.log}}} you
 uploaded:
 ---------------------------

 What's happening
 Line 1741-1742 (and repeated for every configure pass) shows Meson's
 atomics probe:
 {{{
 Checking if "check for -latomic" links: YES
 Library atomic found: YES
 }}}

 Meson found a library called atomic on this system and glib's meson.build
 decided to link against it — -latomic shows up explicitly in the
 libglib-2.0.0.dylib link command (line 6092):
 {{{
 ... glib/libcharset/libcharset.a -latomic -liconv -lintl -lm
 /opt/local/lib/libpcre2-8.dylib -framework Carbon
 }}}

 That's odd on macOS/Clang: unlike GCC on Linux/32-bit ARM, Clang on Darwin
 implements {{{__atomic_* builtins}}} natively — there's normally no
 separate libatomic to link against, and macOS doesn't ship one. So Meson's
 "check for -latomic" test is succeeding here only because something on
 this system provides a library named atomic (likely from a MacPorts-
 installed GCC toolchain sitting in /opt/local/lib, e.g. libgcc/gcc-family
 port that ships a libatomic.dylib/libatomic.1.dylib) — not because glib
 actually needs it.
 The actual crash confirms the theory. At build time (line 6623-6625), g
 -ir-scanner builds and then tries to run a temporary introspection helper
 binary (GLib-2.0), and dyld fails:

 {{{
 dyld[7248]: Library not loaded: @rpath/libatomic.1.dylib
   Referenced from: .../tmp-introspecthov376o1/GLib-2.0
   Reason: tried: [~30 candidate paths, none exist]
 }}}

 So libatomic.1.dylib was findable enough at link time (it's in
 /opt/local/lib on the machine that ran configure) to make the link
 succeed, but at run time, @rpath resolution can't locate it in any of the
 directories glib set up as rpaths (its own build dirs, /opt/local/lib, the
 bootstrap dirs) — meaning it's not actually installed as a proper rpath-
 findable dependency, or it's from a currently-inactive/different-version
 port whose -L/opt/local/lib presence at link time didn't carry through to
 a working runtime path.

 ---------------------------

 I don't know why that is the case and indeed on a "normal" build on
 [https://build.macports.org/builders/ports-
 26_arm64-builder/builds/38840/steps/install-port/logs/stdio macOS 26] the
 log says:

 {{{
 Checking if "check for -latomic" links: NO
 }}}

 I have no idea what the fix is here and will not do any additional work on
 this as I have no way to reproduce it. Anyone interested in resolving this
 ticket is free to do some detective work and submit a PR.

-- 
Ticket URL: <https://trac.macports.org/ticket/74109#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS