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
