Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined)

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."