From: Felix Janda <felix.janda@posteo.de>
To: Eric Biggers <ebiggers@google.com>
Cc: linux-xfs@vger.kernel.org, Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH v2] Fix building xfsprogs on 32-bit platforms
Date: Wed, 30 Nov 2016 19:20:50 -0500 [thread overview]
Message-ID: <20161201001952.GA1318@nyan> (raw)
In-Reply-To: <1480549580-105022-1-git-send-email-ebiggers@google.com>
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.
Sorry, for this breakage. Patch looks good to me except that also the
now unecessary definition of AC_NEED_LFS should be removed from
m4/package_libcdev.m4.
Removing AC_SYS_LARGEFILE also has the advantage that the configure
script does no longer have a --disable-largefile option.
Felix
next prev parent reply other threads:[~2016-12-01 0:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 23:46 [PATCH v2] Fix building xfsprogs on 32-bit platforms Eric Biggers
2016-12-01 0:20 ` Felix Janda [this message]
2016-12-01 0:39 ` Eric Biggers
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=20161201001952.GA1318@nyan \
--to=felix.janda@posteo.de \
--cc=david@fromorbit.com \
--cc=ebiggers@google.com \
--cc=linux-xfs@vger.kernel.org \
/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.