On Thu, 2023-03-09 17:20:01 +0000, Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote: > From: jbglaw%lug-owl.de@localhost > > > > I *guess* a LD_LIBRARY_PATH with '.' or the $DESTDIR/lib or > > something similar sneaked in. > > Nothing in the build uses LD_LIBRARY_PATH,[*] and it is unlikely for > nbmandoc to have been inadvertently linked against a libc that doesn't > exist yet. But from your build log, I see: As I wrote, nbmandoc is called several times beforehand and all these invocations were running perfectly fine. "libc.so.6" is the one on a GNU/Linux system. It starts with libz being build (and nbmandoc links with -lz). > ++ export LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib: > ++ LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib: > > Is that in your build environment? What happens if you remove it? It is! That's from a little to choose between different compilers (ie. a recent GCC snapshot, the "usual" (older) system GCC, some CLANG versions. But that LD_LIBRARY_PATH should in no way enable ld.so to pull in some libz (that's a guess) from the destdir, should it? Just started a build using the sytem compiler (not setting anything). I wonder (read: hope!) that the empty path component doesn't wrongly resolve to "." ... (If the next build succeeds, my next test would be LD_LIBRARY_PATH="/does_not_exist:"...) > [*] Exceptions: bsd.test.mk, not relevant here, only in native builds; > and libexec/httpd/lua/Makefile, for a development-only test > target, not used automatically as far as I know, and not likely > relevant to mandoc or libc issues. As I guess, it's just mandoc showing the symptom: It's linked against -lz and works before libz is build, but as the library emerges, it fails by not finding libc.so.12 (which is NetBSD libc.) MfG, JBG --
Attachment:
signature.asc
Description: PGP signature