This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] manual: Document replacing malloc [BZ #20424]


fweimer@redhat.com (Florian Weimer) writes:
> +linked programs, this happens through ELF symbol interposition.  For
> +static linking, the @code{malloc} replacement library must be linked in
> +before linking against @code{libc.a} (explicitly or implicitly).

Note that in statically linked cases, it's important to make sure that
ALL your API functions are linked in.  If your allocator is a library,
with one function per object, you might get only some of your functions
- and then try to get the rest from glibc, which will of course fail.

> +The @code{malloc} implementation in @theglibc{} provides additional
> +functionality, which is often used by other system libraries and
> +applications.  Failure to provide these functions can lead to linking
> +failures and crashes at run time.  These additional functions are listed
> +in the following table.

Might be useful to clarify that the first list is what glibc itself
needs, and the second is functions not used by glibc but (as noted)
possibly used by your application.

I.e. /functionality/functionality which is not used within glibc itself/

> +Further @code{malloc}-related functions such as @code{mallopt} or
> +@code{mallinfo} will not have any effect or return incorrect statistics
> +when a replacement @code{malloc} is in use.  However, failure to replace
> +these functions typically does not result in crashes or other incorrect
> +application behavior.

mallopt() is in our malloc.c so that would cause a link failure when
static linking, though.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]