Opened 2 years ago

Closed 6 months ago

Last modified 6 months ago

#66287 closed defect (fixed)

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

Reported by: beauby (Lucas Hosseini) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.8.0
Keywords: Cc: peterhurley (Peter Hurley), ShadSterling (Shad Sterling), jeffszuhay (Jeff Szuhay), jmgurney (John-Mark Gurney)
Port: boehmgc

Description

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

Change History (9)

comment:1 Changed 2 years ago by jmgurney (John-Mark Gurney)

I'm seeing this as well.

comment:2 Changed 2 years ago by peterhurley (Peter Hurley)

Cc: peterhurley added

comment:3 Changed 2 years ago by beauby (Lucas Hosseini)

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

comment:4 Changed 7 months ago by ShadSterling (Shad Sterling)

Also seeing this when building +universal on intel

comment:5 Changed 7 months ago by ShadSterling (Shad Sterling)

Cc: ShadSterling added

comment:6 Changed 6 months ago by 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
Last edited 6 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:7 in reply to:  3 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: jeffszuhay jmgurney added
Owner: set to ryandesign
Status: newaccepted

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:

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.

comment:8 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: acceptedclosed

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

comment:9 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)

In 6e6446b78f24640863f74469c7bddf2e00ce8ffe/macports-ports (master):

boehmgc: libatomic_ops is a library dependency

See: #66287

Note: See TracTickets for help on using tickets.