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 -- 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
