boehmgc @8.2.2_0+universal: Failed to destroot boehmgc: bdw-gc.pc differs

[beauby (Lucas Hosseini)]

Attempting to build boehmgc +universal on Apple Silicon, it fails to merge the pkgconfig files:

Error: Failed to destroot boehmgc: bdw-gc.pc differs in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boehmgc/boehmgc/work/destroot-arm64//opt/local/lib/pkgconfig and /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boehmgc/boehmgc/work/destroot-ppc-intel//opt/local/lib/pkgconfig and cannot be merged

[jmgurney (John-Mark Gurney)]

I'm seeing this as well.

[beauby (Lucas Hosseini)]

Note: I provided a patch on GitHub (​https://github.com/macports/macports-ports/pull/16717).

[ShadSterling (Shad Sterling)]

Also seeing this when building +universal on intel

[jeffszuhay (Jeff Szuhay)]

I'm seeing this when building boehmgc-8.2.6_0+universal.darwin_23 on Apple M1 and MacPort2 2.9.3.

--->  Attempting to fetch boehmgc-8.2.6_0+universal.darwin_23.arm64-x86_64.tbz2 from https://packages.macports.org/boehmgc
Error: Failed to destroot boehmgc: bdw-gc.pc differs in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boehmgc/boehmgc/work/destroot-arm64//opt/local/lib/pkgconfig and /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boehmgc/boehmgc/work/destroot-ppc-intel//opt/local/lib/pkgconfig and cannot be merged

[ryandesign (Ryan Carsten Schmidt)]

Replying to beauby:

Note: I provided a patch on GitHub (​https://github.com/macports/macports-ports/pull/16717).

This PR proposed blindly overwriting the arm64 bdw-gc.pc with the x86_64 one. That will not be the solution. The PR was then closed due to the mistaken belief that the problem no longer occurred. After clarification that the problem still occurred, it was then suggested that the universal variant should be disabled. That is also not the best solution, unless no other fix can be found.

The first step in understanding an issue of this type will be seeing how the two files differ. I have done an arm64+x86_64 universal build on my x86_64 macOS 12 machine and reproduced the issue and the difference is:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boehmgc/boehmgc/work/

@@ -6 +6 @@
 Name: Boehm-Demers-Weiser Conservative Garbage Collector
 Description: A garbage collector for C and C++
 Version: 8.2.6
-Libs: -L${libdir}  -lgc -lpthread
+Libs: -L${libdir} -latomic_ops -lgc -lpthread
 Cflags: -I${includedir}

That is, the x86_64 copy does not have -latomic_ops while the arm64 copy does.

Configure output for the x86_64 part said:

:info:configure checking for compiler intrinsics support... yes
:info:configure checking which libatomic_ops to use... none

while for the arm64 part it said:

:info:configure checking for compiler intrinsics support... skipped because cross-compiling
:info:configure checking for atomic_ops.h... yes
:info:configure checking which libatomic_ops to use... external

This difference is surprising because when built non-universally, for either x86_64 or arm64, it does not link with libatomic_ops. The port only declares a build dependency on libatomic_ops, showing that it is not expected that the port will link with the library.

Unfortunately the config.log files provide no clarification for the difference.

Going to the source in configure.ac, it becomes clear:

# Do we want to use an external libatomic_ops?  By default use it if it's
# found.
AC_ARG_WITH([libatomic-ops],
    [AS_HELP_STRING([--with-libatomic-ops[=yes|no|check|none]],
                    [use an external libatomic_ops? (default: check;
                     none: use compiler intrinsics or no thread support)])],
    [], [ AS_IF([test x"$THREADS" != xnone],
                [with_libatomic_ops=check], [with_libatomic_ops=none]) ])

# Check whether compiler atomic intrinsics can be used.
if test x"$with_libatomic_ops" = xcheck; then
  AC_MSG_CHECKING(for compiler intrinsics support)
  old_CFLAGS="$CFLAGS"
  CFLAGS="$CFLAGS $CFLAGS_EXTRA -DGC_BUILTIN_ATOMIC"
  CFLAGS="$CFLAGS -I${srcdir}/include -I${srcdir}/tests"
  AC_TRY_RUN([#include "test_atomic_ops.c"],
    [AC_MSG_RESULT(yes)
     with_libatomic_ops=none],
    [AC_MSG_RESULT(no)], [AC_MSG_RESULT(skipped because cross-compiling)])
  CFLAGS="$old_CFLAGS"
fi

The misleading comment at the top aside, what happens is that when not cross-compiling, it checks if the compiler supports atomic intrinsics, which it does, so it uses that instead of libatomic_ops. But when cross compiling, it doesn't bother checking the compiler's capabilities and uses libatomic_ops.

The fix, therefore, would be to make the port always use libatomic_ops.

[ryandesign (Ryan Carsten Schmidt)]

In 6f948277ce76ed7dc722baa87de254539a26d6d0/macports-ports (master):

boehmgc: Actually use libatomic_ops

Previously, it was only used when cross-compiling, otherwise built-in
compiler atomic intrinsics were used, which caused destroot failure due
to mismatched bdw-gc.pc files.

Closes: #66287

[ryandesign (Ryan Carsten Schmidt)]

In 6e6446b78f24640863f74469c7bddf2e00ce8ffe/macports-ports (master):

boehmgc: libatomic_ops is a library dependency

See: #66287