glib2 @2.88.1_0+universal+x11 configure error

[murrayE]

Error seems to be this:

:info:configure meson.build:2722:2: ERROR: Problem encountered: Running binaries on the build host needs to be supported to build with -Dintrospection=enabled

[murrayE]

main.log

[isolated-matrix]

I'm having a similar problem, but I just noticed something in my log output...

:debug:main Starting logging for glib2 @2.88.1_0+universal+x11
:debug:sysinfo macOS 26.5.1 (darwin/25.5.0) arch arm
:debug:sysinfo MacPorts 2.12.5
:debug:sysinfo Xcode 26.5, CLT 26.5.0.0.1777544298
:debug:sysinfo SDK 26
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 26.0

I know very little about any of this, but could the error be related to the macOS version not being the same as the MACOSX_DEPLOYMENT_TARGET? Could this be fixed using a similar solution as was used for the glib2-bootstrap port (#73976)?

If it would help, I can also attach my own main.log file. A lot of my ports seem to depend on glib2, so it would be nice to finally be able to update them successfully.

[isolated-matrix]

I thought this problem was related to the issue with the universal port group, but, as far as I am aware that issue has now been fixed, but I'm still getting an error at the configuration stage of the updating process... Is there any idea what else might be causing the problem? I'll attach my log file as well, in case it gives you any clues.

[isolated-matrix]

log file from failed glib2 update

[ryandesign (Ryan Carsten Schmidt)]

Replying to isolated-matrix:

I know very little about any of this, but could the error be related to the macOS version not being the same as the MACOSX_DEPLOYMENT_TARGET?

Your major macOS version (26) is the same as your deployment target.

[reneeotten (Renee Otten)]

Replying to isolated-matrix:

I thought this problem was related to the issue with the universal port group, but, as far as I am aware that issue has now been fixed, but I'm still getting an error at the configuration stage of the updating process... Is there any idea what else might be causing the problem? I'll attach my log file as well, in case it gives you any clues.

The log says:

:info:configure meson.build:2722:2: ERROR: Problem encountered: Running binaries on the build host needs to be supported to build with -Dintrospection=enabled
:info:configure A full log can be found at /opt/local/var/macports/build/glib2-1efb34ca/work/build-x86_64/meson-logs/meson-log.txt

can you also add the meson-log.txt file, perhaps that gives some (more) useful information.

As I said in another ticket describing the same issue, I don't build +universal and don't want to rebuild dependencies with +univeral to look into this. So interested parties will have to do the troubleshooting here...

[isolated-matrix]

Thanks for looking into this! I've attached the meson log.

[reneeotten (Renee Otten)]

See ​this PR - can someone please check whether this solves the issue?

[isolated-matrix]

Here's the log file from the glib2 compilation. While it did get past the configuration stage, it failed partway through the build (perhaps related to ​https://trac.macports.org/ticket/74194)

[reneeotten (Renee Otten)]

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 ​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.

[isolated-matrix]

In that case, it looks like this is the same issue as reported in ​https://trac.macports.org/ticket/74194 (I just checked their log file and linked to -latomic for them as well). I guess you can close this ticket, as the failure to configure issue is fixed now; it's now a failure to compile issue.

In which case, I would just merge your previous PR so we can work on the other issue.

[reneeotten (Renee Otten)]

Fixed in this commit