compile failure: conflicting type qualifiers for __malloc_initialize_hook

671 views
Skip to first unread message

Tom Brown

unread,
Jul 6, 2011, 8:20:23 PM7/6/11
to zfs-fuse
I can't get zfs-fuse to compile on 2.6.39-ARCH #1 SMP PREEMPT.
ArchLinux, of course.

The AUR package doesn't work anymore. It's working on a system I put
together in March but both systems stop working if I install from the
AUR. I had to restore the other system from a backup to get zfs-fuse
working.

Here's the error:

gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT malloc.lo -MD -MP -
MF .deps/malloc.Tpo -c malloc.c -fPIC -DPIC -o .libs/malloc.o
malloc.c: In function 'umem_malloc_init_hook':
malloc.c:447:2: warning: '__malloc_hook' is deprecated (declared at /
usr/include/malloc.h:176) [-Wdeprecated-declarations]
malloc.c:449:3: warning: '__malloc_hook' is deprecated (declared at /
usr/include/malloc.h:176) [-Wdeprecated-declarations]
malloc.c:450:3: warning: '__free_hook' is deprecated (declared at /usr/
include/malloc.h:173) [-Wdeprecated-declarations]
malloc.c:451:3: warning: '__realloc_hook' is deprecated (declared at /
usr/include/malloc.h:179) [-Wdeprecated-declarations]
malloc.c:452:3: warning: '__memalign_hook' is deprecated (declared at /
usr/include/malloc.h:183) [-Wdeprecated-declarations]
malloc.c: At top level:
malloc.c:456:8: error: conflicting type qualifiers for
'__malloc_initialize_hook'
/usr/include/malloc.h:170:38: note: previous declaration of
'__malloc_initialize_hook' was here
make[1]: *** [malloc.lo] Error 1
make[1]: Leaving directory `/root/src/official/src/lib/libumem'
make: *** [all] Error 2
scons: *** [lib/libumem/libumem.a] Error 2
scons: building terminated because of errors.

Any ideas?

sgheeren

unread,
Jul 7, 2011, 2:02:11 AM7/7/11
to zfs-...@googlegroups.com
On 07/07/2011 02:20 AM, Tom Brown wrote:
 gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT malloc.lo -MD -MP -
MF .deps/malloc.Tpo -c malloc.c  -fPIC -DPIC -o .libs/malloc.o
malloc.c: In function 'umem_malloc_init_hook':
malloc.c:447:2: warning: '__malloc_hook' is deprecated (declared at /
usr/include/malloc.h:176) [-Wdeprecated-declarations]
malloc.c:449:3: warning: '__malloc_hook' is deprecated (declared at /
usr/include/malloc.h:176) [-Wdeprecated-declarations]
malloc.c:450:3: warning: '__free_hook' is deprecated (declared at /usr/
include/malloc.h:173) [-Wdeprecated-declarations]
malloc.c:451:3: warning: '__realloc_hook' is deprecated (declared at /
usr/include/malloc.h:179) [-Wdeprecated-declarations]
malloc.c:452:3: warning: '__memalign_hook' is deprecated (declared at /
usr/include/malloc.h:183) [-Wdeprecated-declarations]
malloc.c: At top level:
malloc.c:456:8: error: conflicting type qualifiers for
'__malloc_initialize_hook'
/usr/include/malloc.h:170:38: note: previous declaration of
'__malloc_initialize_hook' was here
Firstly, this is quite visibly due to a change to your distribution's malloc.h;

Since the compiler points you at the exact line of the definition, have you tried simply copying the declaration into the zfs-fuse code (presumably libumem?)

ProjectMoon

unread,
Jul 8, 2011, 8:04:32 PM7/8/11
to zfs-fuse
I ran into this issue and found this thread. sgheeren's suggestion
works. makepkg is just a bit finicky. The trick is to just let the
compilation process use Arch's definition of the function by
commenting out the declaration in the zfs-fuse code.

Steps to victory:
1. Run makepkg -s as normal, wait for it to fail.
2. Edit src/official/src/lib/libumem/malloc.c
3. Comment out the declaration of __malloc_initialize_hook
4. Run make inside the libumem directory (this is important)
5. Go back to the top-level directory and run makepkg -e
6. Finish installation as usual.

You have to run make on libumem separately because even though makepkg
-e specifically says it will use the existing source tree, it kept
overwriting my changes to malloc.c.

Now, I haven't tested this extensively, but it builds and I can zfs
list and what have you. I can't think of anything that would go wrong.

ProjectMoon

unread,
Jul 8, 2011, 8:42:15 PM7/8/11
to zfs-fuse
Looks like it segfaults with the -p option, but not when run without
any options. Odd. However, this particular problem was noticed before
on Arch. See the recent AUR comments:
http://aur.archlinux.org/packages.php?ID=8003
Reply all
Reply to author
Forward
0 new messages