Re: Should malloc-related functions be weak?

[Carlos O'Donell <carlos at redhat dot com>]

On 08/01/2016 09:34 AM, Tulio Magno Quites Machado Filho wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
> 
>> * DJ Delorie:
>>
>>> "Tulio Magno Quites Machado Filho" <tuliom@linux.vnet.ibm.com> writes:
>>>> Shouldn't they be weak functions?
>>>
>>> I can imagine the mess that would happen if someone overwrode malloc()
>>> but not free()...
>>
>> The problem is with the other symbols Tulio identified.  I'll try to
>> see if providing weak stubs for them addresses the issue.
> 
> Do you plan to change it for 2.24?
> 
> Let me elaborate...
> Right now, both tcmalloc and jemalloc cannot link statically against glibc
> 2.24 and I'm trying to:
>  - Make they link statically again.
>  - Remove all references to __malloc_initialize_hook (even outdated source
>    code comments).
>  - Stop using all the other malloc hooks.
>  - Improve documentation on this, so that we can provide an answer to the
>    following open questions:
>    - https://sourceware.org/bugzilla/show_bug.cgi?id=2765
>    - https://sourceware.org/bugzilla/show_bug.cgi?id=16939
 
This should not hold up the glibc 2.24 release.

The use case of externally interposed mallocs and static linking is not a case
that should hold up the release. Interposed mallocs might always need to catch
up a bit. I think we should still fix this, but not hold up 2.24.

Therefore please continue to work on this and decide if a 2.24.1 is needed to
address the issue (moving around things internally without changing ABI/API).

-- 
Cheers,
Carlos.