On 2/13/21 9:03 AM, Dimitry Andric 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.


I'm not sure what the best solution is.  Can you file a bug for this and CC 
Louis.

-Tom

-Dimitry


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

Reply via email to