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

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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.

Joerg