Date: Thu, 2 Dec 2021 10:34:35 +0000 From: David Chisnall <theraven@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) Message-ID: <ce2c4b74-b3a2-a17f-42a1-89d665019f28@FreeBSD.org> In-Reply-To: <75CCC6A8-F777-48F9-9AC7-5A08FA9CCD25@FreeBSD.org> References: <20211202020326.GU35602@funkthat.com> <CACNAnaEOmpuJX4yi%2BEFP2NLnv9srC4C5anmfO7mseG_HFfzy%2BA@mail.gmail.com> <75CCC6A8-F777-48F9-9AC7-5A08FA9CCD25@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/12/2021 09:51, Dimitry Andric wrote: > Apparently the "block runtime" is supposed to provide the actual object, > so I guess you have to explicitly link to that runtime? The block runtime provides this symbol. You use this libc API, you must be compiling with a toolchain that supports blocks and must be providing the blocks symbols. If you don't use `atexit_b` or any of the other `_b` APIs then you don't need to link the blocks runtime. I am not sure why this is causing linker failures - if it's a weak symbol and it's not defined then that's entirely expected: the point of a weak symbol is that it might not be defined. This avoids the need to link libc to the blocks runtime for code that doesn't use blocks (i.e. most code that doesn't come from macOS). This code is not using `atexit_b`, but because it is using `atexit` the linker is complaining that the compilation unit containing `atexit` is referring to a symbol that isn't defined. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ce2c4b74-b3a2-a17f-42a1-89d665019f28>