Date: Thu, 2 Dec 2021 15:43:50 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: David Chisnall <theraven@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) Message-ID: <20211202234350.GV35602@funkthat.com> In-Reply-To: <ce2c4b74-b3a2-a17f-42a1-89d665019f28@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
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?20211202234350.GV35602>