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 <jo...@bec.de> 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
