#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)
comment:2 Changed 2 years ago by peterhurley (Peter Hurley)
Cc: | peterhurley added |
---|
comment:3 follow-up: 7 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
comment:7 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | jeffszuhay jmgurney added |
---|---|
Owner: | set to ryandesign |
Status: | new → accepted |
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/
old new 6 6 Name: Boehm-Demers-Weiser Conservative Garbage Collector 7 7 Description: A garbage collector for C and C++ 8 8 Version: 8.2.6 9 Libs: -L${libdir} -lgc -lpthread9 Libs: -L${libdir} -latomic_ops -lgc -lpthread 10 10 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.
comment:8 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
I'm seeing this as well.