On 10-10-2017 17:19, kefu chai wrote:
> On Tue, Oct 10, 2017 at 11:13 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
>> On 10-10-2017 16:58, kefu chai wrote:
>>> On Tue, Oct 10, 2017 at 9:54 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
>>>> On 10-10-2017 15:31, kefu chai wrote:
>>>>> On Tue, Oct 10, 2017 at 8:06 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
>>>>>> On 10-10-2017 13:14, kefu chai wrote:
>>>>>>> + ceph-devel
>>>>>>>
>>>>>>> On Tue, Oct 10, 2017 at 4:49 AM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
>>>>>>>> Hi Kefu,
>>>>>>>>
>>>>>>>> Sort of wondering what in the current code below is the relation between
>>>>>>>> gpertools and tcmalloc?
>>>>>>>
>>>>>>> could you be more specific?
>>>>>>
>>>>>> While looking at the code of CMakeLists.txt:286, in the case that no
>>>>>> ALLOCATOR is defined.
>>>>>> There the current flow of code seems to suggest that gperf-tools is
>>>>>> always linked to tcmalloc. And once gperftools is found, the ALLOCATOR
>>>>>> is set to tcmalloc. This then breaks rocksdb building.
>>>>>> `set(HAVE_LIBTCMALLOC ${GPERFTOOLS_FOUND})`
>>>>>> like:
>>>>>> ```
>>>>>> 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)
>>>>>> ```
>>>>>>
>>>>>>>> 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?
>>>>>>
>>>>>> My bad, I mixed gperf and gperf-tools. We are talking about gperf-tools.
>>>>>> And yes, gperftools brings tcmalloc but not in the version mix that is
>>>>>> asked for. gperf-tools was at 2.5 one time, but has upgraded to 2.6.1_1
>>>>>> on FreeBSD[1]. Getting other versions will require manual work to get it
>>>>>> to work.
>>>>>>
>>>>>> But the question is:
>>>>>> Do I really want my allocator to be tcmalloc when the native
>>>>>> libc allocator is jemalloc?
>>>>>
>>>>> i think it's up to you.
>>>>
>>>> Oke, it is what the code now forces...
>>>> And I've tried avoiding tcmalloc uptil now, and would like to do so for
>>>> the time being..
>>>>
>>>>>> So is the test in CMakeLists.txt:286-324 what we want on FreeBSD?
>>>>>
>>>>> see http://tracker.ceph.com/issues/21422. so again, it's up to you.
>>>>
>>>> The tracker suggests that it is an error in 2.5.93, but
>>>> cmake/modules/BuildRocksDB.cmake suggests that it is only fixed in
>>>> 2.6.2...??
>>>
>>> 2.6.2 is not yet released. so if you want to stick with tcmalloc, you
>>> need to build from the latest (or recent enough) source. actually, i
>>> am not sure what you question is..
>>
>> The question: Do you know if 2.6.2 is the first gperf-tools-version >
>> 2.5.93 where this bug from the tracker is solved?
>
> https://github.com/ceph/ceph/pull/17788/commits/ff8d6a730bb774271b9eea6af338e2d3ce3c48a5
fascinating reading...
Shows that managing version can be a bitch.
>>>>>> The workaround this (for the time being) is to call cmake with
>>>>>> -DALLOCATOR=libc as is suggested.
>>>>
>>>> I'll use this as workaround for the time being, since that is least
>>>> invasive. And when that works out, try and make a PR for the allocator
>>>> selector in CmakeLists.txt, and/or wait until gperf-tools 2.6.2 is
>>>> available on FreeBSD.
>>>
>>> what is issue you want to address?
>>
>> The issue I want to address is that I'm not able to build the intree
>> rocksdb ATM. Because tcmalloc is not => 2.6.2, and tcmalloc is required
>> because gperf-tools is detected.
>
> the error message offered two solutions. i think, what you need is
> just to choose one of them.
Right, so I'm going with libc for the moment...
Thanx for your patient explanations,
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
