I've been building netbsd-N for ages with build.sh, at least back to
netbsd-4. I updated my netbsd-9 tree recently and did an update build,
after a previous successful update build on November 3. The machine in
question has been running NetBSD 9 for a long time; my guess is that I
updated it from 8 in fall of 2020.
I have two oddities, probably unrelated, but:
* stdc++.so.8 not found
When building gcc, I got
rm -f auto-host.h
ln -s /home/n0/gdt/NetBSD-9/src/external/gpl3/gcc/usr.bin/backend/../gcc/arch/earmv7hf/auto-host.h .
if [ -f /home/n0/gdt/NetBSD-9/src/external/gpl3/gcc/usr.bin/backend/../gcc/arch/earmv7hf/sysroot-suffix.h ]; then rm -f sysroot-suffix.h; ln -s /home/n0/gdt/NetBSD-9/src/ext ernal/gpl3/gcc/usr.bin/backend/../gcc/arch/earmv7hf/sysroot-suffix.h ; fi
./gengtype -S /home/n0/gdt/NetBSD-9/src/external/gpl3/gcc/dist/gcc -I gtyp-input.list.tmp -w gtype.state
./gengtype: Shared object "libstdc++.so.8" not found
*** [gtype-desc.h] Error code 1
nbmake[9]: stopped in /home/n0/gdt/NetBSD-9/src/external/gpl3/gcc/usr.bin/backend
1 error
This is odd for two reasons: I would have thought that I had totally
rebuilt my netbsd-9 tree after updating, but on second thought it would
have been stable and not needed. (current is not stable and I end up rm
-rf of objdir from time to time.)
The second oddity is that libstdc++.so.8.0 from my netbsd-8 install is
there, but the symlink to it was not. I recreated the symlink:
lrwxr-xr-x 1 root wheel 16 Jan 2 09:21 /usr/lib/libstdc++.so.8 -> libstdc++.so.8.0
and then gengtype runs.
I was at a loss to explain how the symlink disappeared, but I now
suspect compat80 from rust and removal of compat80 from "pkgin ar". If
add/remove overwrites and removes the symlink, then it's a compat80
package bug to leave the system broken for existing compat after
install/remove.
I find it in the objdir as external/gpl3/gcc/usr.bin/backend/gengtype,
and sure enough it is a NetBSD 8 executable.
Looking in my i386 objdir:
/usr/obj/gdt-9/i386 $ find . -name gengtype | xargs ldd
./tools/gcc/build/gcc/build/gengtype:
-lm.0 => /usr/lib/libm.so.0
-lc.12 => /usr/lib/libc.so.12
./tools/gcc/build/gcc/gengtype:
-lm.0 => /usr/lib/libm.so.0
-lc.12 => /usr/lib/libc.so.12
./external/gpl3/gcc/usr.bin/backend/gengtype:
-lstdc++.8 => /usr/lib/libstdc++.so.8
-lm.0 => /usr/lib/libm.so.0
-lc.12 => /usr/lib/libc.so.12
-lgcc_s.1 => /usr/lib/libgcc_s.so.1
$ find . -name gengtype |xargs file
./tools/gcc/build/gcc/build/gengtype: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 9.2, not stripped
./tools/gcc/build/gcc/gengtype: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 9.2, not stripped
./external/gpl3/gcc/usr.bin/backend/gengtype: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 8.2, not stripped
However, gengtype is not in tools/bin, and it seems like a native
gengtype is being built and used, and that seems off plan. But I guess
it's just part of the gcc build, and doesn't have to be tool-ized.
So mystery solved, and I guess I should make clean in gcc. I have
cleaned and rebuilt tools, but I didn't expect to have to do that other
than tools, since in theory it's cross.
* gawk in compile_et
Somewhere to do with compile_et, I found this (thanks -j !):
gawk: cmd. line:4: warning: regexp escape sequence `\"' is not a known regexp operator
and I wonder why gawk is being used at all.
Attachment:
signature.asc
Description: PGP signature