[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using a different allocator with gnulib

From: Reuben Thomas
Subject: Re: Using a different allocator with gnulib
Date: Fri, 7 Feb 2014 22:31:41 +0000

On 20 May 2011 20:18, Reuben Thomas <address@hidden> wrote:
The one I have in mind is libgc. It seems that


is my only option right now; maybe it is also sufficient (since if I
wanted to use libgc's own API, then I obviously wouldn't be using
gnulib's APIs anyway)?

It has only just come to my attention that this doesn't work; at least, it does, but those are build-time flags for libgc. I don't want to have to rebuild it. As a result, I've been shipping a version of GNU Zile that leaks $ALL_THE_MEMORY since then. Happily(?), no-one else has noticed.

The best solution I can think of is to add the following to my configure.ac:

#define malloc GC_malloc
#define realloc GC_realloc
#define free GC_free
#define strdup GC_strdup
#define strndup GC_strndup

This obviously won't catch any other allocating routine, like asprintf, from glibc. Also, it causes warnings, as it redefines symbols defined in the system headers.

As far as I can tell, the only other allocating routine I use is vasnprintf, which in my case comes from gnulib, which, since it uses config.h too, should get my redefined symbols.

(My test that this works is to run the resultant binary with a breakpoint on GC_malloc: when I add the AH_TOP stanza above, that duly breaks, whereas without it I can happily use Zile without ever hitting it.)

I'd appreciate suggestions for a less fragile method to use gnulib with libgc, and indeed more generally, libgc with the standard API names (obviously there's not a lot I can do about using actual libc functions without building libgc to override libc as above). I'm hoping to use the same technique with a rather bigger program, though not necessarily one that uses a bigger slice of the POSIX API.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]