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(): This is because fork() now calls _malloc_prefork(), and if the application's replacement does not offer this function (as it should not), then the linker is forced to drag in all of jemalloc.o. This of course happens even if the application is not multi-threaded and is not linking against -lpthread. revision 1.15 date: 2020-05-15 07:37:21 -0700; author: joerg; state: Exp; lines: +6 -2; commitid: 85oo6pCrePrJul8C; Hook up proper fork lock handling for malloc: - lock all relevant mutexes just before fork - unlock all mutexes just after fork in the parent - full reinit non-spinlocks in the child This is not using the normal pthread_atfork interface to ensure order of operation, malloc is used as implementation detail too often. For example, here static linking pkgsrc/shells/heirloom-sh: ld: /usr/lib/libc.a(jemalloc.o): in function `malloc': /build/src-current/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2056: multiple definition of `malloc'; mapmalloc.o:/var/package-obj/root/shells/heirloom-sh/work/heirloom-sh-050706/mapmalloc.c:195: first defined here ld: /usr/lib/libc.a(jemalloc.o): in function `calloc': /build/src-current/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2154: multiple definition of `calloc'; mapmalloc.o:/var/package-obj/root/shells/heirloom-sh/work/heirloom-sh-050706/mapmalloc.c:381: first defined here ld: /usr/lib/libc.a(jemalloc.o): in function `realloc': /build/src-current/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2326: multiple definition of `realloc'; mapmalloc.o:/var/package-obj/root/shells/heirloom-sh/work/heirloom-sh-050706/mapmalloc.c:330: first defined here ld: /usr/lib/libc.a(jemalloc.o): in function `free': /build/src-current/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2416: multiple definition of `free'; mapmalloc.o:/var/package-obj/root/shells/heirloom-sh/work/heirloom-sh-050706/mapmalloc.c:303: first defined here Should I send-pr this? Is there any possibility of an "easy" fix? -- 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:
pgpdZr6aJG_yX.pgp
Description: OpenPGP Digital Signature