In article <20200714004900.gb84...@bec.de>, Joerg Sonnenberger <jo...@bec.de> 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 <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.
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
