base 28599a1e5f1b ("sys: add renameat2(2) syscall") was introduced without bumping __FreeBSD_version thus packages do not get a rebuild in e.g. poudriere to expose failing ports. sysutils/coreutils apparently checks for renameat2 and expects RENAME_EXCHANGE from Linux to be supported. [...] --- src/copy.o --- src/copy.c:2154:51: error: use of undeclared identifier 'RENAME_EXCHANGE' 2154 | x->exchange ? RENAME_EXCHANGE : 0) | ^~~~~~~~~~~~~~~ [...] I didn't check further due to lack of time, however building poudriere jail prior to renameat2(2) introduction in base makes sysutils/coreutils to build again in poudriere.
This is something to fix in coreutils and perhaps upstream, not in kernel. Even if I go to implement AT_RENAME_EXCHANGE for some fs in the near future, UFS is definitely not on the short list.
FYI It fails for me the same way in a jailed poudriere on ZFS aarch64 host.
So apparently coreutils checks that renameat() is there, but not whether the RENAME_EXCHANGE define exists?
Created attachment 268700 [details] sysutils/coreutils: attempt to fix renameat macros Here's an attempt to fix the build. It compiles for me, but I'm of course not 100% sure that it will work. I should probably run the test suite, if there is any :)
(In reply to Dimitry Andric from comment #3) Looks like when gnulib (included in coreutils) originally implemented its renameat2, now renameatu due to glibc having added its own renameat2, the intent was to access RENAME_NOREPLACE, which is probably why this was the only macro checked. Probably also an assumption that if RENAME_NOREPLACE exists, the others do as well. coreutils 9.10 is now available but this part of gnulib has not changed since originally implemented, save for changing the included header from Linux's filesystem to <stdio.h>.
Since this breaks 4761 ports (according to bug 292067 comment 56), I think some action is needed? Can portmgr please take a look at it?
(In reply to Dimitry Andric from comment #6) This can be committed as buildfix with portmgr blanket approval.
(In reply to Dimitry Andric from comment #6) If it fixes the build please commit it
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=2f52a07fda6d027d6ef289b7db1e202bf3d41f35 commit 2f52a07fda6d027d6ef289b7db1e202bf3d41f35 Author: Dmitry Salychev <dsl@FreeBSD.org> AuthorDate: 2026-03-11 16:21:20 +0000 Commit: Dmitry Salychev <dsl@FreeBSD.org> CommitDate: 2026-03-16 15:01:32 +0000 sysutils/coreutils: Fix build after 28599a1e5f1b PR: 293672 Approved by: portmgr@ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293672 sysutils/coreutils/files/patch-lib_renameatu.h (new) | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
I can't confirm if ports 2f52a07fda6d fixed it due to lack of testing environment. Anyone is free to close this if port now builds for them.
(In reply to Evgenii Khramtsov (Inactive) from comment #10) For me it builds, but let's keep this open until we get some feedback from the maintainer. Ideally we'd have some patch that we can submit upstream?
(In reply to Dimitry Andric from comment #11) FYI, I fixed this in Gnulib (the file in coreutils is simply copied from there). Here is the commit, if you need it [1]. [1] https://github.com/coreutils/gnulib/commit/3437c9aa655de3b2e38f9024cb43ccc05d23e56d
(In reply to Collin Funk from comment #12) Thanks! I assume that at some point, it will appear in a coreutils release?
(In reply to Dimitry Andric from comment #13) Sorry, I should have mentioned it is in coreutils-9.11. If you update the port to that version, you will likely want this patch [1], which fixes a silly mistake of mine. [1] https://github.com/coreutils/coreutils/commit/0d6fcb99d691d920961938e61c43478566ef626e