From: Dave Chinner <david@fromorbit.com>
To: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [RFC] libxfs: cross-compile fixes
Date: Mon, 19 Sep 2016 15:50:18 +1000 [thread overview]
Message-ID: <20160919055018.GC340@dastard> (raw)
In-Reply-To: <1473493051-12838-1-git-send-email-ralph.sennhauser@gmail.com>
On Sat, Sep 10, 2016 at 09:37:31AM +0200, Ralph Sennhauser wrote:
> ---
>
> Based on the earlier discussion this seems to be the preferred way of
> handling things.
>
> Should I split it into 3 patches?
> Do you want something different to happen when cross-compiling?
>
> Cheers
> Ralph
>
> ---
> configure.ac | 3 +++
> include/builddefs.in | 1 +
> libxfs/Makefile | 10 ++++++++--
> 3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/libxfs/Makefile b/libxfs/Makefile
> index 62608bd..ad492e5 100644
> --- a/libxfs/Makefile
> +++ b/libxfs/Makefile
> @@ -114,11 +114,15 @@ DEBUG = -DNDEBUG
>
> LDIRT = gen_crc32table crc32table.h crc32selftest
>
> +ifeq ($(CROSS_COMPILING),no)
> +BUILD_CFLAGS:=$(CFLAGS)
> +endif
This seems like the wrong place to define something like this. We
define CFLAGS in include/builddefs.in, and I think BUILD_CFLAGS
should be defined there, too. It should probably only drop the
platform specific flags, rather than everything in the corss
compiling case.
> @@ -128,9 +132,11 @@ crc32table.h: gen_crc32table.c
> # busted CRC calculation at build time and hence avoid putting bad CRCs down on
> # disk.
> crc32selftest: gen_crc32table.c crc32table.h crc32.c
> +ifeq ($(CROSS_COMPILING),no)
> @echo " [TEST] CRC32"
> - $(Q) $(BUILD_CC) $(CFLAGS) -D CRC32_SELFTEST=1 crc32.c -o $@
> + $(Q) $(CC) $(CFLAGS) -D CRC32_SELFTEST=1 crc32.c -o $@
> $(Q) ./$@
> +endif
That looks wrong. If CROSS_COMPILING == no, then BUILD_CC has
already been set to CC by the configure script, and CFLAGS is just
fine to use here.
I think what needs to be done here is that the crc32selftest /rule/
needs to be conditional on CROSS_COMPILING, not the /execution/
of the rule. If nothing is dependent on crc32selftest, then it won't
get executed. i.e. this requires dependency manipulation, not
execution changes.
CRC_SRC = crc32table.h crc32.c
ifeq ($(CROSS_COMPILING),no)
TARGETS = crc32selftest
else
TARGETS = $CRC_SRC
endif
default: $TARGETS ltdepend $(LTLIBRARY)
.....
crc32selftest: gen_crc32table.c $CRC_SRC
....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-09-19 5:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1473241376-10922-1-git-send-email-ralph.sennhauser@gmail.com>
2016-09-07 22:27 ` [BUG] xfsprogs-4.7.0: issues cross-compiling for musl Dave Chinner
2016-09-07 22:40 ` Eric Sandeen
2016-09-08 8:41 ` Ralph Sennhauser
2016-09-08 12:13 ` Eric Sandeen
2016-09-08 13:22 ` Ralph Sennhauser
2016-09-08 8:35 ` Ralph Sennhauser
2016-09-09 13:32 ` [PATCH] xfs_io: fix building with musl Ralph Sennhauser
2016-09-09 13:59 ` Eric Sandeen
2016-09-09 17:07 ` Ralph Sennhauser
2016-09-10 7:37 ` [RFC] libxfs: cross-compile fixes Ralph Sennhauser
2016-09-19 5:50 ` Dave Chinner [this message]
2016-09-19 7:32 ` Ralph Sennhauser
2017-01-15 20:32 ` Eric Sandeen
2017-01-16 13:45 ` Ralph Sennhauser
2017-01-16 14:42 ` Eric Sandeen
2017-01-16 14:50 ` Ralph Sennhauser
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=20160919055018.GC340@dastard \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=ralph.sennhauser@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox