libunwind is reentrant and signal safe, and works faster then then
gcc_eh (plus it has some custom patches for problems that have been
found during it's usage in ClickHouse).
gcc_eh may be missing in the system (if gcc was not installed), and
even if it exists clickhouse uses -nodefaultlibs, so some care should be
made to make it work.
Also this library is tiny and there shouln't be any problem to require
it always (there is already tendency to require some contrib libraries,
i.e. poco).
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
This patch also updates the jemalloc version.
Note, that I've enabled page_id for jemalloc
PR_SET_VMA/PR_SET_VMA_ANON_NAME, that requires linux 5.17+ (but ignores
EINVAL anyway).
v2: add -isystem to fix reserved name for JEMALLOC_OVERRIDE___LIBC_PVALLOC
Refs: https://github.com/jemalloc/jemalloc/pull/2304
Refs: https://github.com/ClickHouse/ClickHouse/issues/31531
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
jemalloc provides support for two different libunwind flavors: the original HP libunwind and the one coming with gcc / g++ / libstdc++.
The latter is identified by `JEMALLOC_PROF_LIBGCC` and provides `_Unwind_Backtrace` method instead of `unw_backtrace`.
At the time ClickHouse uses LLVM libunwind which follows libgcc's way of backtracing.
ClickHouse has to provide `unw_backtrace` method by the means of [commit 8e2b31e](8e2b31e766).
While this PR does not allow complete remove of the patch (as ClickHouse itself uses unw_backtrace directly), it definitely sorts the things out.
If you had jemalloc build in contrib/jemalloc, and not current version
but some outdated, then compiler will pick incorrect file and may fail.
Also SYSTEM should be removed since regular -I is in the different list,
and will be checked before -isystem.
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
Make ClickHouse compilable and runnable on risc-v 64
So far only basic functionality was tested (on real hw),
clickhouse server runs, exceptions works, client works,
simple tests works.
What doesn't work:
1. traces - they are always empty
2. system.stack_trace only have first frame
unbundled jemalloc cannot be used, since it includes jemalloc_cpp.o that
contains new/delete overrides, so as clickhouse [1]:
ld.lld: error: duplicate symbol: operator delete(void*, unsigned long)
>>> defined at new_delete.cpp:147 (../src/Common/new_delete.cpp:147)
>>> new_delete.cpp.o:(operator delete(void*, unsigned long)) in archive src/libclickhouse_new_delete.a
>>> defined at jemalloc_cpp.o:(.text+0x160) in archive /usr/lib/x86_64-linux-gnu/libjemalloc.a
[1]: https://clickhouse-builds.s3.yandex.net/15828/35335f07dbf8cab89b4188a674b033c28409dc7b/clickhouse_build_check/build_log_793952627_1602401325.txt
INTERFACE_COMPILE_DEFINITIONS does not work IMPORTED targets:
From 3.6:
Specify compile definitions to use when compiling a given <target>.
The named <target> must have been created by a command such as
add_executable() or add_library() and must not be an Imported Target.
Since 3.11:
Specify compile definitions to use when compiling a given <target>.
The named <target> must have been created by a command such as
add_executable() or add_library() and must not be an ALIAS target.
And this causes the -Wundef warning:
src/Functions/FunctionsHashing.h:1326:5: warning: 'USE_XXHASH' is not defined, evaluates to 0 [-Wundef]
This reverts commit 89419ceb9b
(curl part moved to separate commit)
Squashed:
- termcap removed
- fix for cassandra on apple merged
- cmake: fix "Can't find system zlib library" in unbundled build
- cmake: fix condition when testing for rdkafka platform
- cmake: PROTOBUF_OLD_ABI_COMPAT shouldn't be enabled for internal protobuf
Signed-off-by: Konstantin Podshumok <kpp.live+signed@gmail.com>
In case of OSX jemalloc register itself as a default zone allocator.
But when you link statically then zone_register() will not be called,
and even will be optimized out:
$ nm clickhouse.patched | grep -c zone_register
0
Fix this, by manually calling it.
v2: extern C
Right now it aborts (Abort trap: 6) on osx, the issue does not looks
like [1], but should be investigated, so disable for now.
What is interesting that it works under debugger, so I guess it is
indeed the order of symbol replacements...
[1]: https://github.com/jemalloc/jemalloc/issues/420
And since it does not supported it produces the following warning:
<jemalloc>: No getcpu support: percpu_arena:percpu
<jemalloc>: perCPU arena getcpu() not available. Setting narenas to 8.
However it is uses narenas=ncpu instead of default narenas=ncpu*4
