215 | "bp=(bno 0x%llx, len %u bytes) key=(bno 0x%llx, len %u bytes)\n", 216 | pthread_self(), | ~~~~~~~~~~~~~~ | | | pthread_t {aka struct __pthread *} rdwr.c: At top level: rdwr.c:579:40: error: unknown type name 'off64_t'; did you mean 'off_t'? 579 | __read_buf(int fd, void *buf, int len, off64_t offset, int flags) | ^~~~~~~ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0_musl-j5-20230521-051504 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-gentoo-linux-musl-13 * clang/llvm (if any): clang version 16.0.4 Target: x86_64-gentoo-linux-musl Thread model: posix InstalledDir: /usr/lib/llvm/16/bin Configuration file: /etc/clang/clang.cfg /usr/lib/llvm/16 16.0.4 Python 3.11.3 Available Ruby profiles: [1] ruby30 (with Rubygems) * Available Rust versions: [1] rust-bin-1.69.0 * php cli (if any): go version go1.20.4 linux/amd64 HEAD of ::gentoo commit 10eac2b23ea7edbc360c9fb255eecdf30ec1e512 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Tue May 23 04:31:55 2023 +0000 2023-05-23 04:31:55 UTC emerge -qpvO sys-fs/xfsprogs [ebuild N ] sys-fs/xfsprogs-6.3.0 USE="libedit nls (split-usr) -icu (-selinux)"
Created attachment 862317 [details] emerge-info.txt
Created attachment 862318 [details] emerge-history.txt
Created attachment 862319 [details] environment
Created attachment 862320 [details] etc.clang.tar.bz2
Created attachment 862321 [details] etc.portage.tar.bz2
Created attachment 862322 [details] logs.tar.bz2
Created attachment 862323 [details] sys-fs:xfsprogs-6.3.0:20230523-045150.log
Created attachment 862324 [details] temp.tar.bz2
Created attachment 874139 [details, diff] FEATURE TEST MACRO fix for musl A more elaborate patch should probably detect the availability of the corresponding FTM
(In reply to Sven E. from comment #9) > Created attachment 874139 [details, diff] [details, diff] > FEATURE TEST MACRO fix for musl > > A more elaborate patch should probably detect the availability of the > corresponding FTM As discussed in the tracker bug, this is not a proper fix, and will break with the next musl release.
Sent vimproved's fix upstream at https://lore.kernel.org/linux-xfs/20231105183939.1025279-1-sam@gentoo.org/T/#u.
(In reply to Sam James from comment #10) > (In reply to Sven E. from comment #9) > > Created attachment 874139 [details, diff] [details, diff] [details, diff] > > FEATURE TEST MACRO fix for musl > > > > A more elaborate patch should probably detect the availability of the > > corresponding FTM > > As discussed in the tracker bug, this is not a proper fix, and will break > with the next musl release. I see. Will the alpine patch be limited to musl? Just asking, because a sys w/o file offset bits support might end up producing something with off_t being 32 bits. You'd certainly not want that. Wondering, it seems xfsprogs did use AC_SYS_LARGEFILE some time back, why was that dropped and instead off64_t used esp. since it does not go together with file offset bits but rather largefile64 offset?
