Re: recent changes to pthread_fork.c:fork() cause static linking to fail if the app provides its own malloc()

[christos%astron.com@localhost (Christos Zoulas)]

In article <20200714004900.GB84317%bec.de@localhost>,
Joerg Sonnenberger  <joerg%bec.de@localhost> wrote:
>On Mon, Jul 13, 2020 at 04:28:56PM -0700, Greg A. Woods wrote:
>> At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
>> Subject: Re: recent changes to pthread_fork.c:fork() cause static
>linking to fail if the app provides its own malloc()
>> >
>> > On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote:
>> > > I think it is the following change (and perhaps more similar/related
>> > > changes) which breaks static linking of applications which wish to
>> > > supply their own implementation of malloc(), and which call, e.g.,
>> > > fork():
>> >
>> > I consider it a strong WONTFIX. It's no different from not poviding
>> > posix_memalign etc.
>> 
>> 
>> Well, _malloc_prefork() is explicitly called with an underscore leading
>> the identifier name, so strictly speaking it's invalid for an
>> application to define it.  (and it's not documented, nor in any standard
>> that I can find, with or without the leading underscore).
>
>Replacing malloc is just as invalid from a strict standard compliance
>perspective, so *shrug*
>
>I have absolutely no intention of dealing with more complexity than
>necessary for the libc and libpthread interaction for a fringe case. If
>it fails explicitly, I would actually consider it an improvement.

It is not only _malloc_prefork(), it is also _malloc_postfork() and
_malloc_postfork_child(). The easiest way to fix things is to provide
them as no-op.

christos