LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 43749 - Definition __ZTSPKDu in itanium-base.exp is used for -export_symbol but is really undefined
Summary: Definition __ZTSPKDu in itanium-base.exp is used for -export_symbol but is re...
Status: RESOLVED INVALID
Alias: None
Product: libc++abi
Classification: Unclassified
Component: All Bugs (show other bugs)
Version: 9.0
Hardware: PC MacOS X
: P normal
Assignee: Louis Dionne
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-21 10:50 PDT by Nat!
Modified: 2020-06-01 12:53 PDT (History)
4 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nat! 2019-10-21 10:50:47 PDT
This happens when building on MacOS 10.13. I suppose some parts of the code gets #ifdef-ed out, but the symbollist isn't, that is passed to the linker.
This list is in `lib/itanium-base.exp` and used as input for `-exported_symbols_list`. 

Now Apple's linker decided in its wisdom, that missing actual symbols are an error (and not a warning, what would be sane) and the build aborts.

All affected symbols are of the form _Z.*du. If I remove them before building things work out OK.
Comment 1 Stepan Dyatkovskiy 2020-06-01 11:02:38 PDT
I also have this problem. BTW, is it OK to have itanium symbols on x86_64 arch? Itanium is kind of different thing isn't it?
Comment 2 Louis Dionne 2020-06-01 12:53:37 PDT
What compiler are you using? I'm guessing you're using a fairly old Clang.

The issue is that the compiler emits type information for fundamental types in libc++abi, and your compiler doesn't know about char8_t yet, so it doesn't emit the type information for those. libc++abi tries to export these symbols and it fails to do so, because they haven't been generated in the dylib by the compiler.

Getting a linker error is quite nice, because otherwise you'd be producing a libc++abi.dylib that doesn't work properly at runtime (say if you try to use typeid(char8_t) in your program).

The fix is to use a recent Clang when building libc++ and libc++abi.