CODEWITHSUNDEEP
macoslddarwinmach-olld
blashyrk
blashyrk

Reputation: 107

Darwin `ld` stubbornly won't find symbol that's defined in object file, while `lld` does

When using macOS's built in ld, I get the following error:

ld -arch x86_64 -platform_version macos 11.0 12.2.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -lSystem -lc++ -o /Users/blashyrk/Documents/source/nim/asserttrigger /Users/blashyrk/.cache/nim/asserttrigger_d/asserttrigger.o 

Undefined symbols for architecture x86_64:
  "_nlvmEHPersonality", referenced from:
  Dwarf Exception Unwind Info (__eh_frame) in asserttrigger.o
ld: symbol(s) not found for architecture x86_64

However, that symbol is a function that's defined inside that very same object file. Using objdump on the object file, I can confirm that the function is indeed there:

objdump -t ~/.cache/nim/asserttrigger_d/asserttrigger.o | grep nlvmEH
00000000000063b0 l     F __TEXT,__text _nlvmEHPersonality

And just to make sure I wasn't crazy, I decided to see for myself with Ghidra (please see attached image).

So my question is, what makes macOS's ld not find this symbol? When using LLVM's lld it works, so the symbol is defined properly.

Am I, perhaps, missing a flag? Is ld expecting the EH personality function to be a part of some external object/library?

Here's also a link to the object file, if someone wants to try it out on their end: https://www46.zippyshare.com/v/0UFxM7zD/file.html

The program (if you manage to link it successfully) should run and exit with no output.

Ghidra output

Upvotes: 0

Views: 163

Answers (1)

blashyrk
blashyrk

Reputation: 107

I've gotten it to work by changing the linkage type of nlvmEHPersonality from internal to external.

For some reason, ld64 cant't find it with internal linkage even though lld can.

Upvotes: 0

Related Questions