On Thu, 2 Jul 2026, Greg Troxel wrote:
Stephen Borrill <netbsd%precedence.co.uk@localhost> writes:I am trying to build protobuf on NetBSD 9 from pkgsrc-2026Q2 and have noted the comments in its Makefile about building with GCC 10 (and it did build on NetBSD 10).I am pretty sure that the comments are about a previous problem and you have found a new problem.It correctly determines it require gcc10 (with gcc10-libs as a runtime dependency) to build, but still fails:USE_CXX_FEATURES=c++17 leads to gcc10, is on plan.In file included from /usr/pkg/gcc10/include/c++/ext/string_conversions.h:43, from /usr/pkg/gcc10/include/c++/bits/basic_string.h:6557, from /usr/pkg/gcc10/include/c++/string:55, from /usr/pkg/gcc10/include/c++/bits/locale_classes.h:40, from /usr/pkg/gcc10/include/c++/bits/ios_base.h:41, from /usr/pkg/gcc10/include/c++/ios:42, from /usr/pkg/gcc10/include/c++/istream:38, from /pkg_comp/obj/pkgsrc/devel/protobuf/default/protobuf-35.1/src/google/protobuf/io/zero_copy_stream_impl.cc:24: /usr/pkg/gcc10/include/c++/cstdio:176:11: error: 'vfscanf' has not been declared in '::' 176 | using ::vfscanf; | ^~~~~~~ /usr/pkg/gcc10/include/c++/cstdio:177:11: error: 'vscanf' has not been declared in '::' 177 | using ::vscanf; | ^~~~~~ /usr/pkg/gcc10/include/c++/cstdio:179:11: error: 'vsscanf' has not been declared in '::' 179 | using ::vsscanf; | ^~~~~~~ /usr/pkg/gcc10/include/c++/cstdio:186:22: error: 'vfscanf' has not been declared in '__gnu_cxx' 186 | using ::__gnu_cxx::vfscanf; | ^~~~~~~ /usr/pkg/gcc10/include/c++/cstdio:187:22: error: 'vscanf' has not been declared in '__gnu_cxx' 187 | using ::__gnu_cxx::vscanf; | ^~~~~~ /usr/pkg/gcc10/include/c++/cstdio:189:22: error: 'vsscanf' has not been declared in '__gnu_cxx' 189 | using ::__gnu_cxx::vsscanf; | ^~~~~~~I have a not-100%-reliable memory that it is up to the compiler whether or to require std::foo vs accepting foo, in cases when the standard says std::foo. This feels like a similar situation/problem. I can reproduce your errors, pretty up-to-date netbsd-9, 2026Q2.
This seems to be less an OS-version question and more a question of why the gcc10 pkgsrc package has a different behaviour to the same version when in base:
i.e. % /usr/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/libexec/lto-wrapper Target: x86_64--netbsdConfigured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure --target=x86_64--netbsd --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/support/send-pr.html --with-pkgversion='NetBSD nb2 20230710' --with-system-zlib --without-isl --enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads --with-diagnostics-color=auto-if-env --with-tune=nocona --with-default-libstdcxx-abi=new --with-mpc-lib=/var/obj/mknative/amd64-x86_64/usr/src/external/lgpl3/mpc/lib/libmpc --with-mpfr-lib=/var/obj/mknative/amd64-x86_64/usr/src/external/lgpl3/mpfr/lib/libmpfr --with-gmp-lib=/var/obj/mknative/amd64-x86_64/usr/src/external/lgpl3/gmp/lib/libgmp --with-mpc-include=/usr/src/external/lgpl3/mpc/dist/src --with-mpfr-include=/usr/src/external/lgpl3/mpfr/dist/src --with-gmp-include=/usr/src/external/lgpl3/gmp/lib/libgmp/arch/x86_64 --enable-tls --disable-multilib --disable-libstdcxx-pch --build=x86_64--netbsd --host=x86_64--netbsd --with-sysroot=/var/obj/mknative/amd64-x86_64/usr/src/destdir.amd64
Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.5.0 (nb3 20231008) vs # /usr/pkg/gcc10/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/pkg/gcc10/bin/g++ COLLECT_LTO_WRAPPER=/usr/pkg/gcc10/libexec/gcc/x86_64--netbsd/10.5.0/lto-wrapper Target: x86_64--netbsdConfigured with: ../gcc-10.5.0/configure --disable-libstdcxx-pch --enable-nls --with-libiconv-prefix=/usr --enable-__cxa_atexit --with-gxx-include-dir=/usr/pkg/gcc10/include/c++/ --enable-long-long --with-local-prefix=/usr/pkg/gcc10 --enable-threads=posix --with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/usr/pkg/lib -Wl,-zrelro ' --without-zstd --with-arch=nocona --with-tune=nocona --with-fpmath=sse --with-system-zlib --disable-libssp --enable-languages='c obj-c++ objc fortran c++' --enable-shared --with-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/bin/as --prefix=/usr/pkg/gcc10 --build=x86_64--netbsd --host=x86_64--netbsd --infodir=/usr/pkg/gcc10/info --mandir=/usr/pkg/gcc10/man
Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.5.0 (GCC)
The fix of course is to upgrade from 9, lest you be the last one standing who cares about making things work on 9, which is increasingly feeling like pushing a wet noodle uphill, as we are more than 6y since release, likely 7y since branch, and even more since getting a new compiler. I personally have mostly given up on 9.
Sure - when all customers have migrated off 9: https://www.bsdcan.org/2026/timetable/timetable-NetManager---Building.html -- Stephen