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). So, in my opion it is invalid for unrelated parts of the library to use such an interal function and as a result have conflicts with overriding some functions. Perhaps splitting all the internal definitions out of jemalloc.c into their own compilation units and making sure they don't then also still cause unnecessary inclusion of related code and definitions when referenced would be a possible work-around, but that will no doubt lead to later maintenance headaches. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpih6Na3KhM2.pgp
Description: OpenPGP Digital Signature