bintools-wrapper change causes builds to fail on darwin - ld: Assertion failed

[avdv]

TLDR;

The builds error out with:

ld: Assertion failed: (targetAtom != NULL), function Fixup, file ../../../../ld64/src/ld/ld.hpp, line 776.

Currently effected packages are:

• libmodplug (fixed with libmodplug: Fix build on darwin #106430)
• bazel (2021-02-02: fixed by using clang 7 to build, and removing the -mmacosx-version-min flag -- see bazel: 3.3.1 -> 3.7.2 #105439 (comment))
• bazel-watcher (see bazel-watcher: 0.13.1 -> 0.14.0 #105669 (comment))

@uri-canva bisected this commit 473b341 to be responsible for the error, and verified that reverting that change makes them build again.

---

Seems like libmodplug broke in eval 1628634, when the changes for big sur where merged: #98541 (changes)

Could this be a reason for those linker errors?

Originally posted by @avdv in #105439 (comment)

For posterity:

load_pat.lo modplug.lo -lm 
libtool: link: clang++ -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libmodplug.1.dylib  .libs/sndmix.o .libs/sndfile.o .libs/snd_fx.o .libs/snd_flt.o .libs/snd_dsp.o .libs/fastmix.o .libs/mmcmp.o .libs/load_xm.o .libs/load_wav.o .libs/load_umx.o .libs/load_ult.o .libs/load_stm.o .libs/load_s3m.o .libs/load_ptm.o .libs/load_okt.o .libs/load_mtm.o .libs/load_mod.o .libs/load_med.o .libs/load_mdl.o .libs/load_it.o .libs/load_far.o .libs/load_dsm.o .libs/load_dmf.o .libs/load_dbm.o .libs/load_ams.o .libs/load_amf.o .libs/load_669.o .libs/load_j2b.o .libs/load_mt2.o .libs/load_psm.o .libs/load_abc.o .libs/load_mid.o .libs/load_pat.o .libs/modplug.o   -lm  -g -O2 -mmacosx-version-min=10.5 -mmacosx-version-min=10.5   -install_name  /nix/store/v8hkzrplvwcikdidk761a04by98wjs3j-libmodplug-0.8.9.0/lib/libmodplug.1.dylib -compatibility_version 2 -current_version 2.0 -Wl,-single_module
0  0x10ff56a51  __assert_rtn + 129
1  0x11012f444  ld::passes::stubs::x86_64::classic::LazyPointerAtom::LazyPointerAtom(ld::passes::stubs::Pass&, ld::Atom const&, bool, bool) + 420
2  0x11012cc6a  ld::passes::stubs::Pass::makeStub(ld::Atom const&, bool) + 2762
3  0x11012dc5f  ld::passes::stubs::Pass::process(ld::Internal&) + 2511
4  0x11012e2c0  ld::passes::stubs::doPass(Options const&, ld::Internal&) + 128
5  0x10ff57ff4  main + 1860
A linker snapshot was created at:
        /tmp/libmodplug.1.dylib-2020-10-22-030016.ld-snapshot
ld: Assertion failed: (targetAtom != NULL), function Fixup, file ../../../../ld64/src/ld/ld.hpp, line 776.
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:492: libmodplug.la] Error 1

Seems to happen with clang 6 and clang 7.

[avdv]

On staging-next, it failed in this build first: https://hydra.nixos.org/build/130716618 (2020-11-18 16:22:16), and in the builds that followed: https://hydra.nixos.org/build/130716618/evals

986c2d to 77ff58

[avdv]

Since @uri-canva has identified 473b341 being the culprit for the same linker failure for bazel here, could anyone try to verify whether reverting the change to bintools-wrapper or manually adding the -macosx_version_min 10.12 linker option back makes libmodplug build on darwin again?!

[uri-canva]

Verified reverting the change fixes libmodplug.

[r-burns]

Assertion failure is raised from here:
https://github.com/tpoechtrager/cctools-port/blob/43f32a4c61b5ba7fde011e816136c550b1b3146f/cctools/ld64/src/ld/ld.hpp#L776
I wonder if this is an issue with cctools-port, or the way we package it? Seems like an internal error.

[avdv]

The assumption with the bintools-wrapper change seems to be that clang will add a -macosx_min_version parameter for the linker automatically. But, what happens if it does not do that, or if the build itself adds a -mmacosx-min-version already - just as libmodplug does?

For libmodplug, it fixes the build when we remove the linker flags: e2f0da2

--- a/configure	2020-12-07 14:12:35.422830927 +0100
+++ b/configure	2020-12-07 14:20:22.479538391 +0100
@@ -16731,8 +16731,8 @@
 # require 10.5+ for osx/x86_64 builds
 case "$host" in
 	x86_64-*-darwin*)
-		CXXFLAGS="$CXXFLAGS -mmacosx-version-min=10.5"
-		LDFLAGS="$LDFLAGS -mmacosx-version-min=10.5" ;;
+		#CXXFLAGS="$CXXFLAGS -mmacosx-version-min=10.5"
+		#LDFLAGS="$LDFLAGS -mmacosx-version-min=10.5" ;;
 esac

 # symbol visibility

see successful build

I have no idea why this happens; is 10.5 just too old for the cctools / sdk combo?

[avdv]

Recently I was able to fix building bazel on Darwin. And since trying to build bazel-watcher on top of this fix no longer fails with the linker error we have seen before, I am inclined to close this issue.

I'll open a new one for bazel-watcher which now fails with "fatal error: 'deque' file not found" (or alternatively any other standard C++ header).

[avdv]

Um, actually that was probably too fast. Since bazel-watcher also uses the bazel tools/osx/xcode_configure.bzl it will eventually end up with the same linker error -- only now cannot even get so far.

[andrewhamon]

I think this is still an issue? At least, if I add pkgs.bazel to my shell.nix and try to build my project, I get errors loading headers, e.g.

external/com_google_protobuf/src/google/protobuf/descriptor_database.h:40:10: fatal error: 'map' file not found
#include <map>

I can resolve this by adding both clang and gcc to my shell.nix. Not one or the other, but both. Which feels very odd.

And unfortunately for me, having both gcc and clang present breaks other things (building ruby native extensions).

[avdv]

Closing, since I could successfully build bazel-watcher on Darwin after working around the C++ header problem.