Re: Building NetBSD 11 Release from Source Fails on Linux/MacOS

[Helge Pfeiffer <ropf%itu.dk@localhost>]

Thank you for your reply. Please find my response inlined
below.


On Tue, 2026-11-10 at 23:35 +0000, RVP wrote:
> 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...
> 
Right?

> > 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.
> 
I appreciate this! It makes me feel not alone in wondering
about this issue.

> > - 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/a
> > ors_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.
> 
Thank you for explaining this! I will not do it then (and did
not do it in my experiments. I only thought it would be good
to minimize build times while reproducing the issue.
 
> > ## 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
> > "8d78e500fc95da765a91cddcf2ab7ba71ce4e7997e4f008456d4d872
> > ee8f8221 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.
Thank you very much for doing that! I wonder: When installing
physically, did you choose to enable disk encryption?

Last night, I was thinking that the only difference between
my physical hosts and the virtual machines I created are that
on the physical machines I have disk encryption (LUKS)
enabled. Perhaps, since the build fails on the m4
preprocessor, I thought that LUKS might cause the issue in
some weird way. Therefore, I did a fresh install of Pop OS
24.04 on a Thinkpad x240 without disk encryption and built a
release there. However, it also fails with the same error...

To update on what else I tried: After my last message, I
wanted to create a Qemu disk image that can be used to
reproduce the issue. So, I thought, I just do in a VM the
exact same thing as with the live image described above.
Anyways, there is nothing that I can share. The release build
succeeds also in the Qemu VM (besides in the VirtualBox VMs
that I used during the weekend)... So more weirdness and also
unpractical for sharing reproducible evidence for my issue.  

> 
> 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.
> 
Thank you very much for taking the time to look at these
logs!

Under the following link, you can download a tar archive that
contains build logs and host information for the three OSes
(Pop OS 22.04, Pop OS 24.04, and MacoOS Sequoia) on which I
tried to build NetBSD 11 from source and on which the release
builds fail with the same error when building libgmp.
https://ituniversity-my.sharepoint.com/:u:/g/personal/ropf_itu_dk/IQBgiAB5BluzRIHZ9cyNvZmmASk2qaUoke-7MFtauyseBJY?e=mAPczD

The tar archive contains nine files, three per OS. Per OS,
there is one gzipped log of building the toolchain (parallel
built), which I only include for completeness (perhaps it is
irrelevant, but I think it illustrates that nbm4 is already
used in that build without any issue). Then, there is a file
with gzipped release build logs (built with -j1). Lastly,
there is a plain text file (.host_info) that lists some of
the environment information like compiler, linker, stdlib
versions, etc.

Please let me know if I can produce/share any other
information that might be relevant.

Best,
Helge

> -RVP