On Sat, Feb 16, 2019 at 10:59:14PM +0100, Uwe Kleine-König wrote: > 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 OK, thanks. > 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 I'm used to use this sort of flags for bare-metal/stand-alone stuff but yes, in order to work, you need to have the libs and everything else coherent. > 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. I don't really agree. In the setup you're using, yes 'gcc -mfloat-abi=soft' can't be used but in others ones it's working perfectly (I mean, even with a tool chain configured for armhf by default). > Making this work is a big quest I'd say. Yes, it's also an endless can of worms. Best regards, -- Luc
