[PATCH v3] Fix building xfsprogs on 32-bit platforms

[PATCH v3] Fix building xfsprogs on 32-bit platforms

[Eric Biggers]

xfslibs now requires that its users enable transparent largefile
support.  This broke building xfsprogs on 32-bit Linux (with glibc)
because _FILE_OFFSET_BITS=64 was not getting defined.  Although the
autoconf macro AC_SYS_LARGEFILE was intended to define it, this didn't
work because AC_SYS_LARGEFILE will only define _FILE_OFFSET_BITS in a
config header, which doesn't work for xfsprogs because not all .c files
include platform_defs.h as their first include.  Also,
platform_defs.h.in is not generated by autoheader and didn't contain a
template for _FILE_OFFSET_BITS.

Therefore, to fix the problem remove the useless autoconf macros and
instead add -D_FILE_OFFSET_BITS=64 to CFLAGS in builddefs.in.  Use
CFLAGS rather than PCFLAGS because this definition could be needed by
platforms other than "linux", and it doesn't hurt to always define it.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 configure.ac          |  3 ---
 include/builddefs.in  |  2 +-
 m4/package_libcdev.m4 | 16 ----------------
 3 files changed, 1 insertion(+), 20 deletions(-)

diff --git a/configure.ac b/configure.ac
index b88ab7f..ee918d1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -107,9 +107,6 @@ AC_PACKAGE_UTILITIES(xfsprogs)
 AC_MULTILIB($enable_lib64)
 AC_RT($enable_librt)
 
-AC_SYS_LARGEFILE
-AC_NEED_LFS
-
 AC_PACKAGE_NEED_UUID_H
 AC_PACKAGE_NEED_UUIDCOMPARE
 
diff --git a/include/builddefs.in b/include/builddefs.in
index aeb2905..5219071 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -25,7 +25,7 @@ OPTIMIZER = @opt_build@
 MALLOCLIB = @malloc_lib@
 LOADERFLAGS = @LDFLAGS@
 LTLDFLAGS = @LDFLAGS@
-CFLAGS = @CFLAGS@
+CFLAGS = @CFLAGS@ -D_FILE_OFFSET_BITS=64
 
 LIBRT = @librt@
 LIBUUID = @libuuid@
diff --git a/m4/package_libcdev.m4 b/m4/package_libcdev.m4
index e3c59d8..7d5a42d 100644
--- a/m4/package_libcdev.m4
+++ b/m4/package_libcdev.m4
@@ -258,22 +258,6 @@ AC_DEFUN([AC_HAVE_MREMAP],
   ])
 
 #
-# Check if transparent LFS is enabled
-#
-AC_DEFUN([AC_NEED_LFS],
-  [ AC_MSG_CHECKING([whether large file support works])
-    AC_TRY_COMPILE([
-#include <unistd.h>
-    ], [
-         int i[sizeof(off_t)-8];
-    ], AC_MSG_RESULT(yes),
-       [AC_MSG_RESULT(no)
-       echo
-       echo 'FATAL ERROR: C library does not support transparent LFS.'
-       exit 1])
-  ])
-
-#
 # Check if we need to override the system struct fsxattr with
 # the internal definition.  This /only/ happens if the system
 # actually defines struct fsxattr /and/ the system definition
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH v3] Fix building xfsprogs on 32-bit platforms

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH v3] Fix building xfsprogs on 32-bit platforms

[Felix Janda]

Looks good to me. Thanks!

Reviewed-by: Felix Janda <felix.janda@posteo.de>

Re: [PATCH v3] Fix building xfsprogs on 32-bit platforms

[Eric Biggers]

> xfslibs now requires that its users enable transparent largefile
> support.  This broke building xfsprogs on 32-bit Linux (with glibc)
> because _FILE_OFFSET_BITS=64 was not getting defined.  Although the
> autoconf macro AC_SYS_LARGEFILE was intended to define it, this didn't
> work because AC_SYS_LARGEFILE will only define _FILE_OFFSET_BITS in a
> config header, which doesn't work for xfsprogs because not all .c files
> include platform_defs.h as their first include.  Also,
> platform_defs.h.in is not generated by autoheader and didn't contain a
> template for _FILE_OFFSET_BITS.
> 
> Therefore, to fix the problem remove the useless autoconf macros and
> instead add -D_FILE_OFFSET_BITS=64 to CFLAGS in builddefs.in.  Use
> CFLAGS rather than PCFLAGS because this definition could be needed by
> platforms other than "linux", and it doesn't hurt to always define it.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>

Hi,

Is this patch planned to be applied?  Building 32-bit Linux binaries of xfsprogs
is still broken on the master branch, and there's nothing in for-next.

Eric

Re: [PATCH v3] Fix building xfsprogs on 32-bit platforms

[Eric Sandeen]

On 12/21/16 1:04 PM, Eric Biggers wrote:
>> xfslibs now requires that its users enable transparent largefile
>> support.  This broke building xfsprogs on 32-bit Linux (with glibc)
>> because _FILE_OFFSET_BITS=64 was not getting defined.  Although the
>> autoconf macro AC_SYS_LARGEFILE was intended to define it, this didn't
>> work because AC_SYS_LARGEFILE will only define _FILE_OFFSET_BITS in a
>> config header, which doesn't work for xfsprogs because not all .c files
>> include platform_defs.h as their first include.  Also,
>> platform_defs.h.in is not generated by autoheader and didn't contain a
>> template for _FILE_OFFSET_BITS.
>>
>> Therefore, to fix the problem remove the useless autoconf macros and
>> instead add -D_FILE_OFFSET_BITS=64 to CFLAGS in builddefs.in.  Use
>> CFLAGS rather than PCFLAGS because this definition could be needed by
>> platforms other than "linux", and it doesn't hurt to always define it.
>>
>> Signed-off-by: Eric Biggers <ebiggers@google.com>
> 
> Hi,
> 
> Is this patch planned to be applied?  Building 32-bit Linux binaries of xfsprogs
> is still broken on the master branch, and there's nothing in for-next.

TBH I haven't really tested this on a 32-bit system yet,
I'm sorry.  Right now, I plan to get it into the tree right
after we cut the next release this week.

-Eric


> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v3] Fix building xfsprogs on 32-bit platforms

[Christoph Hellwig]

On Wed, Dec 21, 2016 at 03:33:11PM -0600, Eric Sandeen wrote:
> TBH I haven't really tested this on a 32-bit system yet,
> I'm sorry.  Right now, I plan to get it into the tree right
> after we cut the next release this week.

It would be useful to have it in the release to avoid a regression.

Re: [PATCH v3] Fix building xfsprogs on 32-bit platforms

[Eric Sandeen]

On 12/22/16 2:58 AM, Christoph Hellwig wrote:
> On Wed, Dec 21, 2016 at 03:33:11PM -0600, Eric Sandeen wrote:
>> TBH I haven't really tested this on a 32-bit system yet,
>> I'm sorry.  Right now, I plan to get it into the tree right
>> after we cut the next release this week.
> 
> It would be useful to have it in the release to avoid a regression.

Fair point.  Dave was trying to keep changes down and get a tagged
release out soon, but we certainly shouldn't regress this.
I'll see about getting it in.

Thanks,
-Eric