> On Feb 13, 2021, at 12:04, Dimitry Andric <dimi...@andric.com> wrote:
> 
> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev 
> <llvm-...@lists.llvm.org> wrote:
>> 
>> I've tagged the 12.0.0-rc1 release.  Testers can begin testing and upload 
>> binaries.
> 
> During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest 
> failure, which turned out to be caused by recent libc++ changes:
> 
>  FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
>  cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
> /usr/local/bin/cmake -E env 
> CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
> /usr/local/bin/python3.7 -m unittest discover
>  EEEEEEEE
> 
> The 'EEEEEEEE' signifies 8 errors, which become more clear if "unittest 
> discover" is run with the -f (fail immediately) and -v (verbose) options:
> 
>  $ cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
> /usr/local/bin/cmake -E env 
> CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
> /usr/local/bin/python3.7 -m unittest discover -f -v
>  test_access_specifiers 
> (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
>  Ensure that C++ access specifiers are available on cursors ... ERROR
> 
>  ======================================================================
>  ERROR: test_access_specifiers 
> (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
>  Ensure that C++ access specifiers are available on cursors
>  ----------------------------------------------------------------------
>  Traceback (most recent call last):
>    File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 4173, in get_cindex_library
>      library = cdll.LoadLibrary(self.get_filename())
>    File "/usr/local/lib/python3.7/ctypes/__init__.py", line 442, in 
> LoadLibrary
>      return self._dlltype(name)
>    File "/usr/local/lib/python3.7/ctypes/__init__.py", line 364, in __init__
>      self._handle = _dlopen(self._name, mode)
>  OSError: 
> /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: 
> Undefined symbol "_ZnamSt11align_val_t"
> 
>  During handling of the above exception, another exception occurred:
> 
>  Traceback (most recent call last):
>    File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/test_access_specifiers.py",
>  line 29, in test_access_specifiers
>      """, lang = 'cpp')
>    File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/util.py",
>  line 41, in get_tu
>      source)])
>    File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 2812, in from_source
>      index = Index.create()
>    File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 2699, in create
>      return Index(conf.lib.clang_createIndex(excludeDecls, 0))
>    File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 212, in __get__
>      value = self.wrapped(instance)
>    File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 4147, in lib
>      lib = self.get_cindex_library()
>    File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 4178, in get_cindex_library
>      raise LibclangError(msg)
>  clang.cindex.LibclangError: 
> /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: 
> Undefined symbol "_ZnamSt11align_val_t". To provide a path to libclang use 
> Config.set_library_path() or Config.set_library_file().
> 
>  ----------------------------------------------------------------------
>  Ran 1 test in 0.027s
> 
>  FAILED (errors=1)
> 
> It turns out that libc++.so.1 now depends on the symbol 
> '_ZnamSt11align_val_t', which is 'operator new [](unsigned long, 
> std::align_val_t)'. Embarassingly, libc++.so.1 has always depended on this 
> C++17 specific variant of operator new. But FreeBSD's C++ ABI library, 
> libcxxrt, has never supported this variant!
> 
> Previously, this never was a problem, because libc++ provided its own weak 
> definitions of these operators. But recently the define 
> _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS was toggled to on by default, which 
> disables those definitions. This happened in 
> 9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46 ("[libc++] Define new/delete in 
> libc++abi only by default") by Louis Dionne.
> 
> While this is reasonable for the libc++abi situation, where it might lead to 
> circular dependencies, I would like to turn the definitions on again in case 
> libcxxrt is used for the C++ ABI, such as on FreeBSD.
> 
> If you think this is a reasonable approach, I will create a review for it. 
> Otherwise, I will have to patch the test-release.sh script to pass 
> -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on 
> FreeBSD.

The correct approach would be to have a CMake cache file under 
libcxx/cmake/cache/FreeBSD.cmake that sets the right configuration for building 
libcxx as a system library on freebsd. That way, the cmake code itself can stay 
free of platform specific logic.

Also note that I remember asking vendors before making that change, but I guess 
I either forgot to ask Freebsd or you told me OK without thinking about this. I 
can’t verify which one happened because I’m on my phone, but I’ll check it out 
to make sure I have your contact information if I need to ask that sort of 
questions in the future. It could be useful to have some sort of libcxx-vendors 
group in Phabricator that I could tag whenever I want to ping you folks.

Please send a Phab and I’ll revise it quickly (probably on Monday morning).

Louis

> 
> -Dimitry
> 
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to