[MacPorts] #66287: boehmgc @8.2.2_0+universal: Failed to destroot boehmgc: bdw-gc.pc differs

[MacPorts]

#66287: boehmgc @8.2.2_0+universal:  Failed to destroot boehmgc: bdw-gc.pc differs
----------------------+------------------------
  Reporter:  beauby   |      Owner:  ryandesign
      Type:  defect   |     Status:  accepted
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.8.0
Resolution:           |   Keywords:
      Port:  boehmgc  |
----------------------+------------------------
Changes (by ryandesign):

 * status:  new => accepted
 * owner:  (none) => ryandesign
 * cc: jeffszuhay, jmgurney (added)


Comment:

 Replying to [comment:3 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:

 {{{#!diff
 ---
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boehmgc/boehmgc/work
 /destroot-x86_64/opt/local/lib/pkgconfig/bdw-gc.pc       2024-05-03
 00:39:17.000000000 -0500
 +++
 /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/bdw-gc.pc        2024-05-03
 00:39:15.000000000 -0500
 @@ -6,5 +6,5 @@
  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:

 {{{#!m4
 # 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.

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