Linux XFS filesystem development
 help / color / mirror / Atom feed
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

  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