>> buildman downloads very old compilers (gcc < 4.8) from kernel.org which >> do not support C11. >> Travis CI uses Ubuntu 14.04 with gcc 4.8.4 which incorrectly throws an >> error for disk/part.c in C11 mode. > > ugg, 4.8 is pretty old.. Not sure how much older than 4.8 buildman > uses. It seems like *some* c11 was supported w/ >=4.6 so if we > approach the conversion piecemeal (for example skipping code that > triggers gcc bugs on old compilers) we might be able to keep 4.8.4 > working until travis provides something newer.
For reference el7 (RHEL/CentOS etc) has gcc 4.8.5 > (btw, even going back say 8 fedora releases or more, I've used distro > packaged arm and aarch64 toolchains exclusively.. are there that many > distro's where we really can't assume availability of an > cross-toolchain? If there isn't something newer from kernel.org can > we just drop relying on ancient prebuilt toolchains? I'm anyways not > hugely a fan of downloading binary executables from even kernel.org, > instead of using something from a distro build system which I at least > know is very locked down.) > >> To get things right we would have to >> * build our own cross tool chains based on a current gcc version >> * use our own tool chain in Travis for x86-64 or use a docker >> container with a current gcc version. >> >> In the long run heading for C11 would be the right thing to do. >> Until then use an initializer { '<', 'N', 'U', 'L', 'L', '>' }. >> It looks ugly but does not consume more bytes once compiled. >> > > Sure, that I'm less worried about, as much as adding stuff that is > very soon going to be legacy. Even in vfprintf.c it isn't such a big > deal, as efi_loader where it would be more cumbersome. > > Maybe we can write out u"<NULL>" longhand in vsprintf.c as you > suggest, but restrict efi_loader to gcc >= 4.9? That seems like it > shouldn't be a problem for any arm/arm64 device and it shouldn't be a > problem for any device that is likely to have an efi payload to load > in the first place.. > > BR, > -R > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot