gperftools: Failed to build with lib musl

Originally reported on Google Code with ID 690

What steps will reproduce the problem?
1. unpack source onto x86_64, musl based system
2. apply patch to define __off64_t
3. try to build

What is the expected output? What do you see instead?
Build fails instead of normal completition:
src/malloc_hook_mmap_linux.h: In function 'void* mmap(void*, size_t, int, int, int,
off_t)':
src/malloc_hook_mmap_linux.h:169:18: error: redefinition of 'void* mmap(void*, size_t,
int, int, int, off_t)'
 extern "C" void* mmap(void *start, size_t length, int prot, int flags,
                  ^
In file included from src/malloc_hook.cc:41:0:
src/malloc_hook_mmap_linux.h:155:18: error: 'void* mmap(void*, size_t, int, int, int,
__off64_t)' previously defined here
 extern "C" void* mmap64(void *start, size_t length, int prot, int flags,
                  ^
Makefile:4515: recipe for target 'src/libtcmalloc_minimal_internal_la-malloc_hook.lo'
failed
make: *** [src/libtcmalloc_minimal_internal_la-malloc_hook.lo] Error 1


What version of the product are you using? On what operating system?
Alpine linux 3.0
gcc 4.8.2
musl 1.1.4

Please provide any additional information below.
1. _off64_t is not defined, so I patched base/linux_syscall_support.h to define it
into off64_t
2. musl sys/mman.h is quite different from glibc, so I guess the problem of redifinition
comes from that fact.

I would appreciate for any advice how it could be fixed. Full configure & make logs
attached

Reported by filipp.andronov on 2015-05-15 17:59:04

- _Attachment: [build.log](https://storage.googleapis.com/google-code-attachments/gperftools/issue-690/comment-0/build.log)_ - _Attachment: [10-define-off64-t.patch](https://storage.googleapis.com/google-code-attachments/gperftools/issue-690/comment-0/10-define-off64-t.patch)_

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 30 (16 by maintainers)

Commits related to this issue

fix build with musl libc - use off64_t instead of the internal __off64_t - during configure time, check for __sbrk function. musl libc does not have this. sbrk on musl libc will only work when call... — committed to ncopa/gperftools by ncopa 8 years ago

Most upvoted comments

Would it be an idea to put up a bounty for this and that way accelerate a solution?

I personally would be willing to throw some cash in the pot.

TBK on May 23, 2018

Aha. That is good news. Async-signal-safe is a bit too strong and isn’t quite 100% enough. But we’ll be good in practice I think.

Other mallocs use pthread_mutex-es, which are not AS-safe (but probably good enough in practice). We don’t. We use custom “spinlocks” (and futex-based sleeping). But we do use a bit of pthread facilities for thread local storage. Those are not AS-safe technically, but we’re explicitly prepared to deal with recursive malloc calls from inside those. Well at least for creating pthread local storage key. So we’ll likely be fine too.

Again, don’t expect me to dedicate time for making it happen. But I’ll be happy to review and merge patches (as long as said patches are good).

alk on Apr 20, 2018

@alk It would be very great to have your lib working with Alpine, we need this to get Mongo working on it too. 👍

Thanks.

soullivaneuh on Jun 27, 2016