Dimitry Andric via llvm-dev
2021-Feb-13 17:03 UTC
[llvm-dev] 12.0.0-rc1 Release has been tagged
On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev <llvm-dev at 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. -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210213/931d75db/attachment.sig>
Louis Dionne via llvm-dev
2021-Feb-13 21:44 UTC
[llvm-dev] 12.0.0-rc1 Release has been tagged
> On Feb 13, 2021, at 12:04, Dimitry Andric <dimitry at andric.com> wrote: > > On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev <llvm-dev at 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 >
Tom Stellard via llvm-dev
2021-Feb-19 18:13 UTC
[llvm-dev] 12.0.0-rc1 Release has been tagged
On 2/13/21 9:03 AM, Dimitry Andric wrote:> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev <llvm-dev at 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 >