From: kefu chai <tchaikov@gmail.com>
To: Willem Jan Withagen <wjw@digiware.nl>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: Understanding some of the Cmake logics
Date: Tue, 10 Oct 2017 19:14:09 +0800 [thread overview]
Message-ID: <CAJE9aONEKsSnh7De6-TcS_BwKsCnqav8MXkDR6aUFuMp2out6A@mail.gmail.com> (raw)
In-Reply-To: <b06780c7-13ce-1274-735f-806a1f4f8062@digiware.nl>
+ ceph-devel
On Tue, Oct 10, 2017 at 4:49 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> Hi Kefu,
>
> Sort of wondering what in the current code below is the relation between
> gpertools and tcmalloc?
could you be more specific?
>
> Reason for the question is that once the gperf packages is installed,
> as a bonus the code below declares the allocator to be tcmalloc.
> But gperf under FreeBSD does not have tcmalloc.
please note gperf here is not GNU perf [1] but google-perftools. and
why do you claim the gperf under FreeBSD does not have tcmalloc? could
you elaborate this a little bit?
--
[1] http://portsmon.freebsd.org/portoverview.py?category=devel&portname=gperf
[2] http://portsmon.freebsd.org/portoverview.py?category=devel&portname=google-perftools
>
> So I guess I need to fix the code below the to prevent this implicit
> relation
> under FreeBSD.
>
> And the problem that arises from this all lies in compiling rocksdb,
> because
> under FreeBSD that also needs to be build with libc as allocator.
> The introduction of the new rocksdb building makes this clear.
>
> CMake Error at cmake/modules/BuildRocksDB.cmake:63 (message):
> Incompatible tcmalloc v2.6.1 and rocksdb v5.8.0, please install
> gperf-tools
> 2.5 (not 2.5.93) or >= 2.6.2, or switch to another allocator using 'cmake
> -DALLOCATOR=libc'.
> Call Stack (most recent call first):
> src/CMakeLists.txt:825 (build_rocksdb)
>
>
> --WjW
>
>
> a614c3b9c1e (Ali Maredia 2015-12-30 21:06:08 -0500 286)
> if(ALLOCATOR)
> ca9946d2b5a (Bassam Tabbara 2016-10-10 14:37:58 -0700 287)
> if(${ALLOCATOR} MATCHES "tcmalloc(_minimal)?")
> 6c12edbf9d2 (Kefu Chai 2016-08-11 00:12:05 +0800 288)
> find_package(gperftools REQUIRED)
> 6c12edbf9d2 (Kefu Chai 2016-08-11 00:12:05 +0800 289)
> set(HAVE_LIBTCMALLOC ON)
> a614c3b9c1e (Ali Maredia 2015-12-30 21:06:08 -0500 290)
> elseif(${ALLOCATOR} STREQUAL "jemalloc")
> a614c3b9c1e (Ali Maredia 2015-12-30 21:06:08 -0500 291)
> find_package(JeMalloc REQUIRED)
> 0ef09f32d46 (Ali Maredia 2016-05-02 18:21:32 -0400 292)
> set(HAVE_LIBJEMALLOC ${JEMALLOC_FOUND})
> 83b74f52501 (Matt Benjamin 2016-12-21 23:36:37 -0500 293)
> set(HAVE_JEMALLOC 1)
> a614c3b9c1e (Ali Maredia 2015-12-30 21:06:08 -0500 294) endif()
> a614c3b9c1e (Ali Maredia 2015-12-30 21:06:08 -0500 295)
> else(ALLOCATOR)
> 6c12edbf9d2 (Kefu Chai 2016-08-11 00:12:05 +0800 296)
> find_package(gperftools)
> 6c12edbf9d2 (Kefu Chai 2016-08-11 00:12:05 +0800 297)
> set(HAVE_LIBTCMALLOC ${GPERFTOOLS_FOUND})
> 6c12edbf9d2 (Kefu Chai 2016-08-11 00:12:05 +0800 298) if(NOT
> GPERFTOOLS_FOUND)
> 0ef09f32d46 (Ali Maredia 2016-05-02 18:21:32 -0400 299)
> find_package(JeMalloc)
> 0ef09f32d46 (Ali Maredia 2016-05-02 18:21:32 -0400 300)
> set(HAVE_LIBJEMALLOC ${JEMALLOC_FOUND})
> 6c12edbf9d2 (Kefu Chai 2016-08-11 00:12:05 +0800 301)
> endif(NOT GPERFTOOLS_FOUND)
> 6c12edbf9d2 (Kefu Chai 2016-08-11 00:12:05 +0800 302)
> if(GPERFTOOLS_FOUND)
> 48a1f8eff5b (Kefu Chai 2016-06-08 11:34:44 +0800 303)
> set(ALLOCATOR tcmalloc)
> 48a1f8eff5b (Kefu Chai 2016-06-08 11:34:44 +0800 304)
> elseif(JEMALLOC_FOUND)
> 48a1f8eff5b (Kefu Chai 2016-06-08 11:34:44 +0800 305)
> set(ALLOCATOR jemalloc)
> 48a1f8eff5b (Kefu Chai 2016-06-08 11:34:44 +0800 306) else()
> ce3b71acd20 (Willem Jan Withagen 2017-02-12 15:03:56 +0100 307)
> if(NOT FREEBSD)
> ce3b71acd20 (Willem Jan Withagen 2017-02-12 15:03:56 +0100 308) #
> FreeBSD already has jemalloc as its default allocator
> ce3b71acd20 (Willem Jan Withagen 2017-02-12 15:03:56 +0100 309)
> message(WARNING "tcmalloc and jemalloc not found, falling back to libc")
> ce3b71acd20 (Willem Jan Withagen 2017-02-12 15:03:56 +0100 310) endif()
> a614c3b9c1e (Ali Maredia 2015-12-30 21:06:08 -0500 311)
> set(ALLOCATOR "libc")
> 6c12edbf9d2 (Kefu Chai 2016-08-11 00:12:05 +0800 312)
> endif(GPERFTOOLS_FOUND)
> a614c3b9c1e (Ali Maredia 2015-12-30 21:06:08 -0500 313)
> endif(ALLOCATOR)
>
--
Regards
Kefu Chai
next parent reply other threads:[~2017-10-10 11:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b06780c7-13ce-1274-735f-806a1f4f8062@digiware.nl>
2017-10-10 11:14 ` kefu chai [this message]
2017-10-10 12:06 ` Understanding some of the Cmake logics Willem Jan Withagen
2017-10-10 13:31 ` kefu chai
2017-10-10 13:54 ` Willem Jan Withagen
2017-10-10 14:58 ` kefu chai
2017-10-10 15:13 ` Willem Jan Withagen
2017-10-10 15:19 ` kefu chai
2017-10-10 15:27 ` Willem Jan Withagen
2017-10-10 15:35 ` kefu chai
2017-10-10 15:41 ` Willem Jan Withagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJE9aONEKsSnh7De6-TcS_BwKsCnqav8MXkDR6aUFuMp2out6A@mail.gmail.com \
--to=tchaikov@gmail.com \
--cc=ceph-devel@vger.kernel.org \
--cc=wjw@digiware.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.