On Sep 11, 2025, at 19:49, Dan Mahoney (Ports) <[email protected]> wrote: > >> On Sep 11, 2025, at 5:56 PM, Mark Millard <[email protected]> wrote: >> >> Dan Mahoney (Ports) <freebsd_at_gushi.org> wrote on >> Date: Thu, 11 Sep 2025 23:35:33 UTC : >> >>> Entirely different problem: >>> >>> Build now fails within a minute of starting: >>> >>> https://poudriere-src.isc.org/data/freebsd:16:x86:64-default/2025-09-11_23h25m42s/logs/errors/rust-1.89.0.log >> >> The actual error report in that log file is: >> >> = note: ld: error: undefined symbol: readdir_r >>>>> referenced by std.7afbaec6631a8b5b-cgu.01 >>>>> >>>>> std-3a0e78699a7df230.std.7afbaec6631a8b5b-cgu.01.rcgu.o:(std::sys::fs::unix::remove_dir_impl::remove_dir_all_recursive::hd9cf968a76fe7acb) >>>>> in archive >>>>> /wrkdirs/usr/ports/lang/rust/work/bootstrap/lib/rustlib/x86_64-unknown-freebsd/lib/libstd-3a0e78699a7df230.rlib >>>>> did you mean: readdir_r@FBSD_1.5 >>>>> defined in: /lib/libc.so.7 >> cc: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> Your poudriere jail's world is a version of FreeBSD 16 >> that had readdir_r removed, breaking builds of rust. >> >> FreeBSD has had that removal reverted. You need to update >> the poudriere jail's world content to be of a vintage that >> includes: >> >> • git: d20c82507278 - main - Revert "libc: Remove readdir_r(3)" Dag-Erling >> Smørgrav > > Aah, so at some point, I guess I had a 16 vm, which was failing due to a > memory limit, then tried updating to try and fix that, but at the same time > as fixing the ram issue, so I was no longer memory bound, but now in the > broken state. Whoops, perfect timing. > > I've updated now, and we're once again building. (I have both a jail built > from src and one that uses pkgbase, trying both). > >>> My entire poudriere-conf is: >> >> Is the "-" a typo? The normal name is: poudriere.conf > > It was a typo, yes. > >> >> "USE_TMPFS=yes" means that much of the file system >> space usage is competing for the system's RAM+SWAP >> space instead of for disk space. >> >> Having something like, say, SWAP=3.6*RAM [so >> (RAM+SWAP)=4.6*RAM] is a possibility that will >> page the part of the time that RAM is insufficient. >> >> Otherwise you probably want more like: USE_TMPFS=data >> > > This is what I've done. > > Let's see if it works. Rust builds so fast, after all...
I'll note that there is another option that I'd not mentioned: use of TMPFS_BLACKLIST and TMPFS_BLACKLIST_TMPDIR with USE_TMPFS=yes or USE_TMPFS=all or the like to specifically cause the rust package to not use tmpfs for file system storage for the most part. Depending on what you build, there are other port packages that have similar or larger file system usage requirements. More than rust might be listed. Port package names (not origins) are what to list in TMPFS_BLACKLIST . There are some port-packages that use fairly large file system space during builds even for USE_TMPFS=data and being listed in TMPFS_BLACKLIST : TMPFS_BLACKLIST does not apply to the USE_TMPFS=data file system usage. Using MUTUALLY_EXCLUSIVE_BUILD_PACKAGES with any that create problems can be appropriate if one is allowing multiple builders to run in parallel. I'll note that if you use USE_TMPFS=data you can likely allow significantly more parallel building activity, say via ALLOW_MAKE_JOBS=yes and possible MAKE_JOBS_NUMBER_LIMIT use (if needed). === Mark Millard marklmi at yahoo.com
