ld Assertion failed: (target->definition() != ld::Atom::definitionProxy) while building Haskell project

You’ve clearly tripped an assertion within the linker. That is, by definition, a bug in the linker [1], and I’d appreciate you filing it as such. You’ll get more traction if you attach the build artefacts required to reproduce the problem (that is, all the .o files) because I don’t think our linker engineers have Haskell installed (-: Oh, and the assertion references a file, /tmp/libHSfuturice-integrations-0-inplace-ghc8.10.7.dylib-2022-00-08-222023.ld-snapshot, that’s likely to be helpful.

Please post your bug number, just for the record.

The backtrace you posted suggests that this is related to chained fixups, a new feature that’s on by default on modern systems. I know that you’re running the linker an Apple silicon, but are you also building for Apple silicon? Or are you building for Intel on Apple silicon?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Even if GHC is doing something wrong, the linker should print a nice diagnostic rather than crash.

Thanks! Filed feedback with the output and /tmp/...ld-snapshot contents. Bug number is 9839914.

Yes, building for Apple silicon on Apple silicon.

$ ghc --info
 ,("target platform string","aarch64-apple-darwin")
 ,("target os","OSDarwin")
 ,("target arch","ArchAArch64")
 ,("LLVM target","arm64-apple-darwin")
 ,("Build platform","aarch64-apple-darwin")
 ,("Host platform","aarch64-apple-darwin")
 ,("Target platform","aarch64-apple-darwin")

Bug number is FB9839914.

Thanks.

Yes, building for Apple silicon on Apple silicon.

OK.

Given that, I have one suggestion that might lead to a short-term workaround. If you set your deployment target to macOS 11 (currently I suspect it’s defaulting to macOS 12), does that help? You can do this using the -macos_version_min option, documented in the ld man page.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I tried -optl-mmacosx-version-min=11.0 and MACOSX_DEPLOYMENT_TARGET=11.0 which both resulted in many warnings like ld: warning: dylib (/opt/homebrew/lib/libpq.dylib) was built for newer macOS version (12.0) than being linked (11.0) followed by the same ld assertion failure.

Yeah, that’s a challenge. Homebrew builds from source and always sets the deployment target to the current system version, and the linker gets grumpy if you try to mix deployment targets (and rightly so!).

You could try building your dependencies on macOS 11, then copying them across to macOS 12, then re-running this test. Honestly though, I’m not sure it’s worth the effort going further down this path because…

I got some preliminary feedback on your bug report. Earlier I wrote:

Even if GHC is doing something wrong, the linker should print a nice diagnostic rather than crash.

It seems that GHC is doing something wrong and our resolution for this bug will be to convert that assert into a proper error message. You should get the details via official channels soon. If you don’t hear from our bugs folks by this time next week, drop me a line via email (my email address is in my signature; also, make sure to reference this thread ’cause I get way too much email :-).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We are also having this problem on Scala Native with LTO thin as detailed in this ticket. https://github.com/scala-native/scala-native/issues/2779

This also happens with brew installed toolchain.

% clang --version
Homebrew clang version 14.0.6
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin

I could probably create a small reproduction if needed.

Can you reproduce this with the Xcode 14 toolchain? My reading of FB9839914 is that it should be fixed there.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, using the Apple tools I get the following:

Here is my tools version and I am on OS version 12.6.3

% clang --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Here is the command issued:

clang++
-rdynamic
-flto=thin
-o
<omited>/scala-native/sandbox/.3/target/scala-3.1.3/native/Test
-Wno-override-module
<omited> all .o file
-L/usr/local/lib
-L/opt/homebrew/lib
-lpthread
-ldl
-lpthread

Here is the output:

[info] Compiling to native code (1967 ms)
[error] 0  0x104efc0c0  __assert_rtn + 140
[error] 1  0x104f05038  ld::tool::SymbolTableAtom<arm64>::addImport(ld::Atom const*, ld::tool::StringPoolAtom*) (.cold.1) + 0
[error] 2  0x104e0ef90  ld::tool::SymbolTableAtom<arm64>::addGlobal(ld::Atom const*, ld::tool::StringPoolAtom*) + 1176
[error] 3  0x104e0e640  ld::tool::SymbolTableAtom<arm64>::encode() + 216
[error] 4  0x104dfb23c  ___ZN2ld4tool10OutputFile20buildLINKEDITContentERNS_8InternalE_block_invoke_3 + 36
[error] 5  0x18687a5f0  _dispatch_call_block_and_release + 32
[error] 6  0x18687c1b4  _dispatch_client_callout + 20
[error] 7  0x18688db14  _dispatch_root_queue_drain + 952
[error] 8  0x18688e104  _dispatch_worker_thread2 + 164
[error] 9  0x186a3c324  _pthread_wqthread + 228
[error] A linker snapshot was created at:
[error] 	/tmp/Test-2023-03-20-085021.ld-snapshot
[error] ld: Assertion failed: (_machoSection != 0), function machoSection, file ld.hpp, line 1311.
[error] clang: error: linker command failed with exit code 1 (use -v to see invocation)

OK, then it’s time for a new bug. FB9839914 has been closed as fixed, so either that’s wrong or this is a subtly different issue.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Oh, and in another context ekrich noted that they were unable to follow the FB link above. This is expected, alas. Bug reports are only visible to the folks who filed them. For more about this whole process, see my Bug Reporting: How and Why? post.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I also met the same problem, when I increase the minimum Deployments in Xcode from 14 to 15.5 to compile, this error appears, when I change the minimum Deployments from 15.5 back to 14 everything is back to normal, if I want to upgrade to 15.5 What should I do to compile and pass. My compilation error is: Assertion failed: (reconstituted == (accumulator - _options.machHeaderVmAddr())), function setFixup64, file OutputFile.cpp, line 2964. I am using Xcode version 14.3.1 System version macOS 13.4.1

there is a way to work around add "-ld64" to "OTHER_LDFLAGS" it works for m

Right. But that’s a workaround, and one that probably won’t last forever. If history repeats itself [1] then, at some point, ld_prime will become the only option, and you need to make sure that whatever’s causing this issue is resolve before then.

Which brings me back to my advice from earlier: If you can still reproduce the problem with the latest Xcode beta (or its associated command-line tools) then you really need to file a bug report about that.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I have some backstory about this in An Apple Library Primer.