tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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: pgppI6Rrd4lrR.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index