Re: [lldb-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged
On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev
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
The '' 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.
-Dimitry
signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] 12.0.0-rc1 Release has been tagged
> On Feb 13, 2021, at 12:04, Dimitry Andric wrote:
>
> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev
> 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
>
>
> The '' 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 conf
