On 2/16/19 12:36 PM, Luc Van Oostenryck wrote: > 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'? Right. On the arm64 porter box (uname -m -> aarch64) when entering an armhf chroot I get: $ uname -m armv8l So the problem with the reproducible stuff might only happen because uname is modified on purpose. >>> ... 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. I wonder if gcc is happy with this. I just tried gcc -mfloat-abi=soft test.c -o test on an armhf system and it failed with /usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error: gnu/stubs-soft.h: No such file or directory According to https://packages.debian.org/search?searchon=contents&keywords=stubs-soft.h&mode=path&suite=unstable&arch=any this file is provided by libc6-dev on armel, but I think even installing that won't make gcc happy as the path where the file is provided isn't considered. So I'd say it's ok if cgcc -mfloat-abi=soft fails on armhf, too. Making this work is a big quest I'd say. We'd need something like "properties" like endianess, pointer-size and float handling and then categorize the needed cpp-symbols to be active only when certain properties are "active". Best regards Uwe
Attachment:
signature.asc
Description: OpenPGP digital signature
