I saw a 32-bit build failure, but it looked like a legitimate bug, unrelated to the compiler version. Here's the trivial fix:
diff --git a/ioctl.h b/ioctl.h index a7235c0..26a3a5a 100644 --- a/ioctl.h +++ b/ioctl.h @@ -606,7 +606,7 @@ struct btrfs_ioctl_send_args { * Size of structure depends on pointer width, was not caught. Kernel handles * pointer width differences transparently */ -BUILD_ASSERT(sizeof(__u64 *) == 8 +BUILD_ASSERT(sizeof(__u64) == 8 ? sizeof(struct btrfs_ioctl_send_args) == 72 : (sizeof(void *) == 4 ? sizeof(struct btrfs_ioctl_send_args) == 68 -Justin On Wed, Oct 5, 2016 at 6:33 AM, David Sterba <dste...@suse.cz> wrote: > I got a report that the 32bit builds are broken. This seems to be caused > by padding inserted (or not) into the structures and depends on a > compiler version. The error messages may look cryptic, but if you see > something like > > ioctl.h:570:1: note: in expansion of macro 'BUILD_ASSERT' > BUILD_ASSERT(sizeof(struct btrfs_ioctl_received_subvol_args) == 200); > > that means that the given structure has an unexpected size. Fixing that > properly will probably lead to some tricks to force the exact size > regardless of arch bits and compiler. > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html