On 2 Dec 2021, at 06:42, Kyle Evans <kev...@freebsd.org> wrote: > > On Wed, Dec 1, 2021 at 8:05 PM John-Mark Gurney <j...@funkthat.com> wrote: >> >> Hello, >> >> It seems like the recent changes to make --no-allow-shlib-undefined >> broke pructl. >> >> lib/libc/stdlib/atexit.c uses a weak _Block_copy symbol, but >> pructl does not use atexit_b, and yet gets the following error: >> : && /usr/bin/cc -Werror -O2 -pipe -fstack-protector-strong -isystem >> /usr/local/include -fno-strict-aliasing -std=c99 -fstack-protector-strong >> CMakeFiles/pructl.dir/pructl.c.o -o pructl -Wl,-rpath,/usr/local/lib: >> /usr/local/lib/libpru.so && : >> ld: error: /lib/libc.so.7: undefined reference to _Block_copy >> [--no-allow-shlib-undefined] >> cc: error: linker command failed with exit code 1 (use -v to see invocation) >> >> What is the correct fix? It seems like atexit.c or the linker should >> be fixed, as pructl doesn't use atexit_b at all. >> > > CC dim@ and jrtc27@... this seems like a toolchain regression? We're > relying on the address of weak _Block_copy to simply evaluate to NULL > if it's undefined here, which seems legit and pretty well-defined at > this point from my recollection.
What do you mean exactly with "here"? In libc? In atexit? In libpru? I
can't make it out from the context, sorry. :)
As far as I can see, _Block_copy has always been a weak undefined symbol
in libc.so:
4: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Block_copy
Apparently the "block runtime" is supposed to provide the actual object,
so I guess you have to explicitly link to that runtime?
I know next to nothing about the blocks stuff, so it's all pretty much
unknown territory to me... :)
-Dimitry
signature.asc
Description: Message signed with OpenPGP
