On Fri, Feb 15, 2019 at 10:38:44PM +0100, Uwe Kleine-König wrote: > On 2/15/19 9:13 PM, Luc Van Oostenryck wrote: > > Please note that (as far as I can think) if you're on a platform A > > and cross-compile sparse for platform B and then use sparse (with o > > without cgcc) on this platform B, then everything should be OK. > > OTOH, I'm not sure I understand exactly what is done in this > > reproducibility test here. > > This is not really a cross-compile situation. It's just that the second > builder isn't a native armhf machine, but it runs an arm64 kernel and > the build is done in an armhf chroot. OK, and what is the -dumpmachine of the compiler used to compile sparse in this chroot? 'arm-linux-gnueabihf'? > > ... even if cgcc is made somehow > > 'cross-platform aware', I'm pretty sure there will be many others > > problems. > > ... But using gcc -dumpmachine should do the right > thing here, so my patch goes in the right direction I think. Yes, for sure using 'gcc -dumpmachine' won't give worst result than using 'uname -m'. What I meant was that here we have a problem with __ARM_PCS_VFP which must be set by default for arm-linux-gnueabihf. But this flag must also be set for arm-linux-gnueabi if used with -mfloat-abi=hard and must not be set for arm-linux-gnueabihf with -mfloat-abi=soft or -mfloat-abi=softfp. Each archs have several, sometimes dozen, other such sort of things where gcc's target (and otherconfiguration choices) and the options efectively used must be taken in account to give correct resuls. For ARM, a non-exhaustive list is: __APCS_32__, __ARMEL__ __ARM_32BIT_STATE, __ARM_ARCH, __ARM_ARCH_7A__, __ARM_ARCH_ISA_ARM, __ARM_ARCH_ISA_THUMB, __ARM_EABI__, __ARM_FEATURE_<feature>, __ARM_FP, __ARM_NEON_FP, __VFP_FP__, ... (and that's just for preprocessor things). MIPS is most probably the worst with all its ABI choices which can then be changed further with more options (like -mfp64, -mgp32). Best regards, -- Luc
