- it is already done in in find/ccache.cmake
- it does not respect disabling ccache
- it does not allow to override ccache using custom location (not in
PATH)
c-ares searching for gethostbyname in the libnsl library, however in the
version that shipped with gRPC it doing it wrong [1], since it uses
CHECK_LIBRARY_EXISTS(), which will return TRUE even if the function exists in
another dependent library. The upstream already contains correct macro [2],
but it is not included in gRPC (even upstream gRPC, not the one that is
shipped with clickhousee).
[1]: e982924ace/CMakeLists.txt (L125)
[2]: 44fbc81368/CMakeLists.txt (L146)
And because if you by some reason have libnsl [3] installed, clickhouse will
reject to start w/o it. While this is completelly different library.
[3]: https://packages.debian.org/bullseye/libnsl2
qemu does not support MADV_DONTNEED, and by not support it simply ignore
it (i.e. return 0 -- no error).
This issue has been "fixed" in #15590, however it just
terminates the process, and completely breaks clickhouse under qemu
(see also #15174).
But there is no need in such strong protection, we can stop using
madvise in jemalloc if MADV_DONTNEED does not work properly.
And this is what #18169 was tried to do (by override madvise), however
this will break sanitizers, at least TSAN and UBSAN.
The problem there is that sanitizers initialization code uses madvise
(and there is no way to turn this off with TSAN_OPTIONS) and overwritten
madvise function will have sanitizers traits (__tsan_func_entry), while
TSAN is not ready for this, and eventually it SIGSEGV.
Interesting thing is that in the recent clang-12, madvise was replaced
with direct syscall [1].
[1]: 9f8c4039f2
But it is better to make clickhouse compatible with clang < 12 too, so
instead of override madvise completely, the runtime check was moved into
the jemalloc code [2].
[2]: https://github.com/ClickHouse-Extras/jemalloc/pull/1
In incremental_copy_fast_path there is undefined behavior (and in some
other places too).
And under this circumstances gcc10 with -O1 -ftree-loop-vectorize (or
simply -O3), due to loop unroll, generates code that do copy by 16 bytes
at a time for the second loop (MOVDQU+MOVUPS), while this is not correct
since the memory may be overlapped and may be changed in the previous
iteration.
Updated version includes [1], that fixes those UB, by using memcpy over
direct store/load since these days direct store/loads looks redundant.
Even on ARM.
[1]: https://github.com/ClickHouse-Extras/librdkafka/pull/3
NOTE: clang is fine, and other older versions of gcc too
