Details
- Reviewers
lntue - Commits
- rG4e6c30c8354f: [libc] Add a separate algorithm_test.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thx @lntue.
I've been able to reproduce the error with cmake fullbuild -> ninja llvmlibc -> ninja check-libc
And indeed, from a clean CMake folder cmake fullbuild -> ninja check-libc passes.
I've extracted both compilation command lines and they are identical. This is puzzling.
/redacted_home/build-llvm/download/clang/bin/clang++ --sysroot=/redacted_home/build-llvm/download/sysroot -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/redacted_home/llvm-project_rel_compiled-with-clang/projects/libc/test/src/string/memory_utils -I/redacted_home/git/llvm-project/libc/test/src/string/memory_utils -I/redacted_home/llvm-project_rel_compiled-with-clang/include -I/redacted_home/git/llvm-project/llvm/include -I/redacted_home/git/llvm-project/libc -I/redacted_home/llvm-project_rel_compiled-with-clang/projects/libc -I/redacted_home/llvm-project_rel_compiled-with-clang/projects/libc/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -UNDEBUG -march=znver3 -std=c++17 -MD -MT projects/libc/test/src/string/memory_utils/CMakeFiles/libc.test.src.string.memory_utils.algorithm_test.dir/algorithm_test.cpp.o -MF projects/libc/test/src/string/memory_utils/CMakeFiles/libc.test.src.string.memory_utils.algorithm_test.dir/algorithm_test.cpp.o.d -o projects/libc/test/src/string/memory_utils/CMakeFiles/libc.test.src.string.memory_utils.algorithm_test.dir/algorithm_test.cpp.o -c /redacted_home/git/llvm-project/libc/test/src/string/memory_utils/algorithm_test.cpp
Ok I get it, kind of. #include <string> in the tests pulls a reference to pthread down in the GCC C++ library. I don't quite understand why but this is is resolved to llvm libc's header in the cmake build directory /redacted_home/llvm-project_rel_compiled-with-clang/projects/libc/include/pthread.h.
But that header is incomplete, the following symbols are missing : pthread_key_t, pthread_once_t, pthread_cond_broadcast, pthread_cond_signal, pthread_cond_wait, pthread_cond_timedwait.
Looking at the cmd line though, I can't find anything responsible for preferring llvm-libc headers over the system ones.
In fact I think we should have two types of tests:
- Unit tests testing internal building blocks,
- Functional tests testing the behavior of the libc interface.
In full build mode we should only run functional tests (2), this would allow us to use standard C++ in 1.
This can be done by splitting the add_libc_unittest function in : add_libc_unittest and add_libc_functionaltest
We could either have a separate functionaltest folder at the root of the project.
What do you think @sivachandra @courbet @michaelrj @lntue ?
In the meantime we could disable algorithm_test when FULLBUILD is enabled.
As I've mentioned before I'm all for splitting off tests into those that do not need to . I've seen the pain of all these patches re-implementing basic functionality for gtest and libc++. If we remain in that situation we'll end up not unit testing enough.
@lntue let me know if this looks good to you so I can move on with my refactoring. I'm currently blocked on this :)
It's Independence Day today so I don't expect any discussions to occur before Wed. I will submit this now. We can revert later if you disagree.