On Mon, 9 Nov 2026, Helge Pfeiffer wrote:
| OS | VM VirtualBox | VM VirtualBox Min. Env. |
|---------------|-----------------------|-------------------------|
| ubuntu22.04 | tools YES release YES | tools YES release YES |
| ubuntu24.04 | tools YES release YES | tools YES release YES |
| debian-13 | tools YES release YES | tools YES release YES |
| popos-22.04 | tools YES release YES | tools YES release YES |
| freebsd14 | tools YES release YES | tools YES release YES |
| OS | Bare Metal | Bare Metal Min. Env. |
|--------------------|-----------------------|-----------------------|
| ubuntu22.04 | tools YES release NO | tools YES release NO |
| popos-22.04 | tools YES release NO | tools YES release NO |
| popos-24.04 | tools YES release NO | tools YES release NO |
| MacOS Sequoia ZSH | tools YES release NO | tools YES release NO |
| MacOS Sequoia BASH | tools YES release NO | tools YES release NO |
| MacOS Montery | tools YES release YES | tools YES release YES |
That is, in the virtual machines, I can build a NetBSD 11 release from source
for all the configurations.
That table is bizarre--can't think of an explanation...
It looks as if it does not matter if LC_ALL=C or a default value as Ramiro
reported (or C.UTF-8 or en_US.UTF-8 as for me in most cases).
That was a good call, but, no it doesn't seem to matter. I was building with
LANG=en_GB.UTF-8 and LANG=C.UTF-8 in my tests. NetBSD's build system will
override the locale to `C' where its needed.
These results leave me scratching my head.
Me too.
- Since the release build always fails when nbm4 is preprocessing files while
building libgmp, one can directly make only this dependency with the respective
make wrapper:
`$HOME/obj/tooldir.Linux-*-generic-x86_64/bin/nbmake-amd64 -C
netbsd-11-src/external/lgpl3/gmp/lib/libgmp
- That step fails with the following output:
```
/path/to/disk/obj/tooldir.Linux-7.0.11-76070011-generic-x86_64/bin/nbm4
-DCONFIG_TOP_SRCDIR=/path/to/disk/netbsd-11-src/external/lgpl3/gmp/lib/libgmp/../../dist
-I/path/to/disk/netbsd-11-src/ external/lgpl3/gmp/lib/libgmp
-I/path/to/disk/netbsd-11-src/external/lgpl3/gmp/lib/libgmp/dummy
-I/path/to/disk/netbsd-11-src/external/lgpl3/gmp/lib/libgmp/../../dist/
-I/path/to/disk/ netbsd-11-src/external/lgpl3/gmp/lib/libgmp/../../dist/mpn
-I/path/to/disk/netbsd-11-src/external/lgpl3/gmp/lib/libgmp -DPIC
-DOPERATION_sub_err1_n /path/to/disk/netbsd-11-src/external/lgpl3/
gmp/lib/libgmp/../../dist/mpn/x86_64/aors_err1_n.asm > sub_err1_n.s
nbm4: unexpected end of input, unclosed parenthesis:
/path/to/disk/netbsd-11-src/external/lgpl3/gmp/lib/libgmp/../../dist/mpn/x86_64/aors_err1_n.asm
at line 225
I wouldn't do this in this for libgmp. While you can use that method for most
of NetBSD's own dirs, building external dependencies, like libgmp here, doesn't
work as expected. I tried this and it built all the object files into the
source dir. itself, and then subsequent further builds crapped out. I had to
remove that entire `src/external/lgpl3/gmp/lib/libgmp' tree and restore it from
the pristine sources for things to work.
## How to reproduce my issue?
```
cd ~/Downloads
wget
https://iso.pop-os.org/24.04/amd64/generic/28/pop-os_24.04_amd64_generic_28.iso
echo "8d78e500fc95da765a91cddcf2ab7ba71ce4e7997e4f008456d4d872ee8f8221
pop-os_24.04_amd64_generic_28.iso" | sha256sum --check
sudo dd if=./pop-os_24.04_amd64_generic_28.iso of=/dev/sda bs=4M
status=progress`
cd /path/to/disk
git clone --depth 1 https://github.com/NetBSD/src.git -b netbsd-11
netbsd-11-src
./build.sh -U -u -P -j6 -m amd64 -a x86_64 -O $HOME/obj release
```
Well, I did exactly that:
a) wrote and booted a Pop! OS 24.0 live instance on bare metal
b) git cloned
c) ./build.sh using the command above.
and, as before, with Ubuntu 26.04 on real HW, the build went past libgmp w/o a
glitch. It only failed due to lack of disk space on the live instance.
Try doing a release build with `-j1' wherever it doesn't work, then upload the
complete build log file (./build.sj -j1 ... > /tmp/b.log 2>&1) somewhere, and
post a link so that it can be examined.
-RVP
