From: Cyril Hrubis <chrubis@suse.cz>
To: Dave Chinner <david@fromorbit.com>
Cc: Xiao Yang <yangx.jy@cn.fujitsu.com>,
ltp@lists.linux.it, linux-xfs@vger.kernel.org
Subject: Re: [LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check
Date: Mon, 17 Oct 2016 11:16:14 +0200 [thread overview]
Message-ID: <20161017091614.GA26999@rei.lan> (raw)
In-Reply-To: <20161013194613.GP23194@dastard>
Hi!
> > That kind of looks like a bug in xfs-progs, since off64_t is not exposed
> > from glibc unless we enable either largefile support or define
> > _GNU_SOURCE. As a matter of fact the _GNU_SOURCE enables
> > _LARGEFILE64_SOURCE which then enables the typedef that exposes the
> > off64_t typedef.
>
> Which is a bug in the application build - if you are doing anything
> with XFS, you need to define _LARGEFILE64_SOURCE. No ifs, buts or
> maybes - it's a 64 bit filesystem with 64 bit interfaces (e.g.
> ioctls) and so applications that include XFS headers to poke at XFS
> filesystems need to fully support 64 bit file offsets....
Ok, so this was our fault.
Is there somewhere bit fat warning that I've missed somewhere?
> > So they are depending on a type that is not defined by default but since
> > the code has been part of at least three releases already we have to
> > apply the workaround for it anyway.
>
> We're only going to get stricter on this - next cycle we're removing
> off64_t and replacing it with off_t, and then we'll be /explicitly/
> breaking the build of any application that hasn't set up it's build
> environment to define off_t as a 64 bit variable. i.e. specifying
> _LARGEFILE64_SOURCE before the inclusion of XFS headers will be a
> mandatory requirement - that's far better than ending up with clean
> builds and subtly broken applications...
Ending the build with clear #error or something similar sounds much
better than failing with undefined type to me.
--
Cyril Hrubis
chrubis@suse.cz
WARNING: multiple messages have this Message-ID (diff)
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check
Date: Mon, 17 Oct 2016 11:16:14 +0200 [thread overview]
Message-ID: <20161017091614.GA26999@rei.lan> (raw)
In-Reply-To: <20161013194613.GP23194@dastard>
Hi!
> > That kind of looks like a bug in xfs-progs, since off64_t is not exposed
> > from glibc unless we enable either largefile support or define
> > _GNU_SOURCE. As a matter of fact the _GNU_SOURCE enables
> > _LARGEFILE64_SOURCE which then enables the typedef that exposes the
> > off64_t typedef.
>
> Which is a bug in the application build - if you are doing anything
> with XFS, you need to define _LARGEFILE64_SOURCE. No ifs, buts or
> maybes - it's a 64 bit filesystem with 64 bit interfaces (e.g.
> ioctls) and so applications that include XFS headers to poke at XFS
> filesystems need to fully support 64 bit file offsets....
Ok, so this was our fault.
Is there somewhere bit fat warning that I've missed somewhere?
> > So they are depending on a type that is not defined by default but since
> > the code has been part of at least three releases already we have to
> > apply the workaround for it anyway.
>
> We're only going to get stricter on this - next cycle we're removing
> off64_t and replacing it with off_t, and then we'll be /explicitly/
> breaking the build of any application that hasn't set up it's build
> environment to define off_t as a 64 bit variable. i.e. specifying
> _LARGEFILE64_SOURCE before the inclusion of XFS headers will be a
> mandatory requirement - that's far better than ending up with clean
> builds and subtly broken applications...
Ending the build with clear #error or something similar sounds much
better than failing with undefined type to me.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2016-10-17 9:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 1:52 [LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check Xiao Yang
2016-10-13 14:11 ` Cyril Hrubis
2016-10-13 14:11 ` Cyril Hrubis
2016-10-13 19:46 ` Dave Chinner
2016-10-13 19:46 ` Dave Chinner
2016-10-17 9:16 ` Cyril Hrubis [this message]
2016-10-17 9:16 ` Cyril Hrubis
2016-10-18 0:04 ` Dave Chinner
2016-10-18 0:04 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161017091614.GA26999@rei.lan \
--to=chrubis@suse.cz \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=yangx.jy@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.