libcxxbi, itanium symbols for Mac OS 10.13

Hi Louis!

I found your commit in llvm-project, libcxxabi, namely this one:

commit 223df5b54021cfa4c67d4e09e1dc1b3b9e6a9de7 (refs/bisect/bad)
Author: Louis Dionne ldionne@apple.com

In this commit you added exported symbols for different platforms for libcxxabi, for apple:

I’m currently trying to build it for Mac OS 10.13.6, x86_64, and bumped into unresolved symbols errors:

Undefined symbols for architecture x86_64:
“__ZTIDu”, referenced from:
-exported_symbol[s_list] command line option
“__ZTIPDu”, referenced from:
-exported_symbol[s_list] command line option

I noticed that you added itanium-base.exp for APPLE platforms by default (no other conditions):

if (APPLE)

target_link_libraries(cxxabi_shared PRIVATE “-Wl,-exported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/…/lib/itanium-base.exp”)

I’m not expert of x86_64 arch, especially for darwin. Are we using Itanium ABI by default on Mac OS 10.13 for x86_64 arch?
If so, what did I miss, for there are symbols which must be exported, but absent in my compilation. I compile libcxxabi with following commands:

cmake -G “Ninja” -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$BUILD_DIR/install -DLLVM_ENABLE_PROJECTS=“libcxx;libcxxabi” $SRC_DIR
ninja -j8

There is also bug, which seems to be related to this commit:
https://bugs.llvm.org/show_bug.cgi?id=43749

Thanks!
Stepan Dyatkovskiy

Hi,

I just updated http://llvm.org/PR43749, which I wasn’t aware of. As I explain in the bug report:

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).

I hope that answers your question. The problem should go away if you use a recent Clang. If it doesn’t please ping me again.

Thanks,
Louis

Louis,
how recent clang should be? I have this error for 31th of May version, for this commit 595212569.

Thanks!

I’m sorry, I reproduced this issue only with clang version which is 4 weeks old. Commit ff4a3ee4.
It wasn’t yet tested with newer clang versions. I’ll check tomorrow and let you know.

Thanks!
Stepan

Nope, it fails for TOT as well.

commit e70cf280f80c0933dd500ff18c7a17af8057b28c (HEAD → master, origin/master, origin/HEAD)
Author: Sam Parker sam.parker@arm.com

[NFC][ARM][AArch64] Test runs

Add code size tests runs for memory ops for both architectures.

Error message:

Undefined symbols for architecture x86_64:
“__ZTIDu”, referenced from:
-exported_symbol[s_list] command line option
“__ZTIPDu”, referenced from:
-exported_symbol[s_list] command line option
“__ZTIPKDu”, referenced from:
-exported_symbol[s_list] command line option
“__ZTSDu”, referenced from:
-exported_symbol[s_list] command line option
“__ZTSPDu”, referenced from:
-exported_symbol[s_list] command line option
“__ZTSPKDu”, referenced from:
-exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture x86_64

Thanks!
Stepan

Hmm, something like a year old clang should work, so this must be an actual bug. Can you provide a link to a gist containing the full output of the build command? Also, please use -v so we can see individual compiler invocations.

Thanks,
Louis

We find it builds fine with an Xcode clang > 1001. It does not build with the latest Xcode clang available on 10.13, but it does build with clang-9.0 on 10.13 (just confirmed it with your build line).

Here’s a log from 10.13 successfully building libc++abi.dyib (and the rest of clang) using clang-9 last night.

<https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/85088/steps/install-port/logs/stdio>.

hope this helps,

K

  • ldionne@

Ken, Louis,

After all also can confirm similar conditions.

  1. It won’t built latest Xcode clang I was able to get for 10.13, namely this one:

Apple LLVM version 10.0.0 (clang-1000.10.43.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

  1. I was only able to get it pass through with the following bootstrap sequence:
    2.1. Get TOT llvm
    Phase 1
    2.2. Build it with clang enabled and with static libcxx and libcxxabi projects enabled. So, following options should be “OFF” in cmake:
  • LIBCXXABI_ENABLE_SHARED
  • LIBCXX_ENABLE_SHARED
    Note, “check-cxx” rule will give you a lot of errors on this step. Just because there are no shared libs.
    2.3. install it into custom dir
    Phase 2
    2.4. Build libcxx and libcxx with CMAKE_C_COMPILER and CMAKE_CXX_COMPILER set to toolchain you get on step 2.3.
    2.5. Install into desired dir. The result would be working libcxx and libcxxabi (both static and shared).

Conclusions.
Solutions mentioned in this thread are quite different from standard guidelines. May be we should update them?

-Stepan

Just to be clear – I didn’t have to do any of that.

Just

  1. install clang-9.0
  2. use it to build TOT with the build line you outlined

export CXX=/path/to/clang+±9.0

export CC=/path/to/clang-9.0

cmake -G “Ninja” -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$BUILD_DIR/install -DLLVM_ENABLE_PROJECTS=“libcxx;libcxxabi” $SRC_DIR
ninja -j8

done.

Ken

How to install it? macports only? Brew?

Either would likely work – or from llvm-9.0 tree yourself.

Ken

PS. Not to distract, but same approach (using clang-9.0 as a stepping stone to build TOT) works all the way back to at least 10.6.8, btw, with minor tweaks.