Date: Sat, 4 Dec 2021 10:10:45 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: David Chisnall <theraven@FreeBSD.org>, freebsd-current@freebsd.org Subject: Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) Message-ID: <20211204181045.GW35602@funkthat.com> In-Reply-To: <20211202234350.GV35602@funkthat.com> References: <20211202020326.GU35602@funkthat.com> <CACNAnaEOmpuJX4yi%2BEFP2NLnv9srC4C5anmfO7mseG_HFfzy%2BA@mail.gmail.com> <75CCC6A8-F777-48F9-9AC7-5A08FA9CCD25@FreeBSD.org> <ce2c4b74-b3a2-a17f-42a1-89d665019f28@FreeBSD.org> <20211202234350.GV35602@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote this message on Thu, Dec 02, 2021 at 15:43 -0800: > David Chisnall wrote this message on Thu, Dec 02, 2021 at 10:34 +0000: > > 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. > > I assume that this failure was due to a recent llvm change, because I > haven't received any failures about pructl until Nov 16th, 2021, > despite the port and code being untouched since 2020-09-22. > > Digging in a bit more, it looks like libpru is compiled w/ -fblocks, > and so depending upon the _Block_copy symbol, the atexit is just the > "closest" symbol that's defined". pructl is not, but even compiling > pructl w/ -fblocks, doesn't fix the link error, as it looks like the > block runtime isn't linked. If I manually include > /usr/lib/libBlocksRuntime.so, then pructl is able to link. > > I can't seem to find any docs on clang about how to properly compile > code that uses blocks, so, unless someone points me to docs on how to > compile blocks enable programs, I'll just patch libpru to not use > blocks since it seems like blocks is well supported. I don't want > to fix this code every few years when things change. Thanks to some off-list comms, it appears that this was a regression in lld 13, and will be fixed by: https://reviews.llvm.org/D115041 Thanks to jrtc27 for [helping] tracking this down! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20211204181045.GW35602>