On 2/20/23 13:14, Pádraig Brady wrote: > Since https://github.com/coreutils/gnulib/commit/4db8db34 > gnulib has been unconditionally replacing lseek() on macos. > Now with SEEK_DATA undefined that replaced lseek() > will run the code intended for BeOS. > So either the lseek.m4 or lseek.c needs adjusting accordingly. Good catch, thanks. I updated the Gnulib patch accordingly; see attached. On 2/20/23 02:21, George Valkov wrote: > What is the correct way to apply your patch? Sounds like patching is a bit of a hassle, so to make things easier I installed the attached patch into Gnulib, and propagated this into Coreutils. You should be able to get the latest version of Coreutils from savannah.gnu.org, and then run './bootstrap; ./configure; make' if you have suitable development tools like Autoconf. You can run ./bootstrap on a GNU/Linux platform and then copy the directory to macOS and run './configure; make' on macOS. Please give it a try. > If you know what conditions are required to reproduce the issue on FreeBSD, I don't. I'm relying on FreeBSD bug report 256205. I cited that in the attached patch. > Is it ok if I continue testing on FreeBSD 13.1 Sure, that's fine. Possibly the bug is fixed in FreeBSD 13.1; if so, perhaps we can improve performance on 13.1 by changing "__FreeBSD__ < 14" to something else. On 2/20/23 13:25, George Valkov wrote: > there is no need for that hack in lseek.c. Yes, we don't need any new hack in lseek.c. And strictly speaking, even the existing macOS-specific hack in lseek.c (look for __APPLE__) is no longer needed, since (with the changes I just installed) lseek.c is no longer compiled for macOS. However, assuming Apple fixes the macOS bug in (say) macOS 14, so that we change the "99990000" to "140000" in Gnulib's lib/unistd.in.h and m4/lseek.m4, we'll likely need that hack back because it works around an incompatibility between GNU-or-FreeBSD-or-Solaris SEEK_DATA and macOS SEEK_DATA; see . So I thought it nicer to leave it in for now; it has zero runtime cost on all platforms.