Re: btrfs-progs-v4.12: cross compiling

[Eric Sandeen <sandeen@redhat.com>]

On 8/15/17 7:48 AM, David Sterba wrote:
> On Tue, Aug 15, 2017 at 02:44:07PM +0200, Hallo32 wrote:

...

>>>> How the kernel deals with this kind of problem ?
>>>> Looking at the source of btrfs Makefile, it is more simple to replace
>>>>
>>>>    mktables: kernel-lib/mktables.c
>>>>          @echo "    [CC]     $@"
>>>>          $(Q)$(CC) $(CFLAGS) $< -o $@
>>>>
>>>> with
>>>>
>>>>
>>>>    mktables: kernel-lib/mktables.c
>>>>          @echo "    [HOSTCC] $@"
>>>>          $(Q)$(HOSTCC) $(CFLAGS) $< -o $@
>>>>
>>>> where HOSTCC is defined as
>>>>
>>>> HOSTCC=gcc
>>>>
>>>>
>>>> (may be the same applied also to CFLAGS <-> HOSTCFLAGS ?)
>>>
>>> If using HOSTCC then I'm fine with it.
>>
>> CFLAGS needs also be replaced by something like HOSTCFLAGS, because if 
>> you use something like mips/architecture specific CFLAGS, they may be 
>> not applicably on the host system.
> 
> Good point. Without a regular/automated cross-compilation build testing
> I think we could break it quite easily. I'm going to keep the
> pregenerated file in git.

Isn't using the host compiler for some binaries during a cross-compile
a very standard thing to do?

The kernel manages it, as shown above.  xfsprogs does it (see libxfs/Makefile
for the crc32table.h and crc32selftest targets), e2fsprogs does it (see
gen_crc32ctable target in lib/ext2fs/Makefile), etc.

Seems that checking in a generated file would be more prone to eventual
errors, no?

I guess it's harder to do in btrfs-progs since it's not using autotools...

-Eric