On 2017年08月16日 01:28, Eric Sandeen wrote:
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.
Only if I can find it earlier.
Seems that checking in a generated file would be more prone to eventual
errors, no?
Also my concern.
I guess it's harder to do in btrfs-progs since it's not using autotools...
And your patch does do a better job, especially for BUILD_CFLAGS and
build cc detection.
Thanks,
Qu
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
