[libcxx-dev] libcxxbi, itanium symbols for Mac OS 10.13

Tue Jun 2 09:20:29 PDT 2020

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

hope this helps,

K

> On Jun 2, 2020, at 6:42 AM, Louis Dionne via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> 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
> 
>> On Jun 2, 2020, at 04:50, llvm at dyatkovskiy.com <mailto:llvm at dyatkovskiy.com> wrote:
>> 
>> Nope, it fails for TOT as well.
>>  
>> commit e70cf280f80c0933dd500ff18c7a17af8057b28c (HEAD -> master, origin/master, origin/HEAD)
>> Author: Sam Parker <sam.parker at arm.com <mailto:sam.parker at arm.com>>
>> Date: Tue Jun 2 09:04:20 2020 +0100
>>  
>> [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
>>  
>> 02.06.2020, 02:50, "via libcxx-dev" <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>>:
>> 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
>>  
>> 02.06.2020, 01:12, "via libcxx-dev" <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>>:
>> Louis,
>> how recent clang should be? I have this error for 31th of May version, for this commit 595212569.
>>  
>> Thanks!
>>  
>> 01.06.2020, 23:54, "Louis Dionne" <ldionne at apple.com <mailto:ldionne at apple.com>>:
>> Hi,
>>  
>> I just updated http://llvm.org/PR43749 <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
>>  
>> On Jun 1, 2020, at 15:39, llvm at dyatkovskiy.com <mailto:llvm at dyatkovskiy.com> wrote:
>>  
>> Hi Louis!
>>  
>> I found your commit in llvm-project, libcxxabi, namely this one:
>>  
>> commit 223df5b54021cfa4c67d4e09e1dc1b3b9e6a9de7 (refs/bisect/bad)
>> Author: Louis Dionne <ldionne at apple.com <mailto:ldionne at apple.com>>
>> Date: Thu Jun 27 20:17:22 2019 +0000
>>  
>> 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 <https://bugs.llvm.org/show_bug.cgi?id=43749>
>>  
>> Thanks!
>> Stepan Dyatkovskiy
>>  
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>>  
>>  
>>  
>>  
>> ,
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200602/159b207c/attachment-0001.html>