[U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

Peter Robinson pbrobinson at gmail.com
Wed Aug 9 08:50:30 UTC 2017

>> 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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

More information about the U-Boot mailing list