All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: linux-xfs@vger.kernel.org
Cc: Dave Chinner <david@fromorbit.com>,
	Eric Sandeen <sandeen@redhat.com>,
	Eric Biggers <ebiggers@google.com>,
	Felix Janda <felix.janda@posteo.de>
Subject: Re: [PATCH v3] Fix building xfsprogs on 32-bit platforms
Date: Wed, 21 Dec 2016 11:04:13 -0800	[thread overview]
Message-ID: <20161221190413.GA136777@gmail.com> (raw)
In-Reply-To: <1480552932-614-1-git-send-email-ebiggers@google.com>

> 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

  parent reply	other threads:[~2016-12-21 19:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01  0:42 [PATCH v3] Fix building xfsprogs on 32-bit platforms Eric Biggers
2016-12-02 13:13 ` Christoph Hellwig
2016-12-03 15:21 ` Felix Janda
2016-12-21 19:04 ` Eric Biggers [this message]
2016-12-21 21:33   ` Eric Sandeen
2016-12-22  8:58     ` Christoph Hellwig
2016-12-22 15:09       ` Eric Sandeen

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=20161221190413.GA136777@gmail.com \
    --to=ebiggers3@gmail.com \
    --cc=david@fromorbit.com \
    --cc=ebiggers@google.com \
    --cc=felix.janda@posteo.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.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.