Hide Forgot
Description of problem: In file included from /usr/include/xfs/xfs.h:37:0, from conftest.c:86: /usr/include/xfs/linux.h:145:9: error: unknown type name 'off64_t' typedef off64_t xfs_off_t; ^~~~~~~ This can be worked around by using -D_GNU_SOURCE, but that should not be necessary. Version-Release number of selected component (if applicable): xfsprogs-devel-4.5.0-1.fc25.x86_64 (Also affects upstream xfsprogs from git) How reproducible: 100% Steps to Reproduce: 1. Include <xfs.h> in any program. Additional info: Discussed upstream with no resolution: https://www.spinics.net/lists/fstests/index.html#02640 This breaks Ceph in Rawhide.
FWIW, this breaks ceph builds in f23 too.
cb898f1 linux.h: Use off64_t instead of loff_t seems to have undone: f96aff0 xfsprogs: stop using off64_t in platform headers
Sorry, this one kind of fell off my radar. Should we just #define _LARGEFILE64_SOURCE ? The original reason for the change back to off64_t was: commit cb898f157f8410a03cf5f3400baa1df9e5eecd33 Author: Felix Janda <felix.janda> Date: Fri Feb 5 08:34:06 2016 +1100 linux.h: Use off64_t instead of loff_t These are equivalent on glibc, while musl does not know loff_t. In the long run, it would be preferable to enable transparent LFS so that off64_t could be replaced by off_t. Signed-off-by: Felix Janda <felix.janda> Reviewed-by: Christoph Hellwig <hch> Signed-off-by: Dave Chinner <david> So I'm not really quite sure where to go with this one.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
I'm probably going to just revert the type change for now, this seems remarkably complicated to fix in general for all architectures and libc variants. It may end up that we require a 64-bit LFS compile when including xfs.h in the long run, though.
AFAIK this should all be fine now - sorry it took a while. If not, please re-open...