On Fri, Aug 4, 2017 at 4:28 PM, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > On 08/04/2017 09:31 PM, Rob Clark wrote: >> For now, pending conclusion on proposal about using c11 and u"string" >> instead of L"string" plus -fshort-wchar. >> >> Background: UEFI uses utf16 strings universally. An UEFI implementation >> that does not use -fshort-wchar has to do a lot of cumbersome charset >> conversion back/forth. Mixing object files that use -fshort-wchar and >> others that do not is a bad idea (and gcc will warn about it). There >> are 3 reasonable solutions that I can think of: >> >> 1) Use -fshort-wchar across the board. We don't dynamically link >> against other shared libraries at runtime, so there isn't much >> downside to this approach. Heinrich brought up ext4, which uses >> utf32, but I guess this mostly matters for fs_ls(), and it does >> not seem so bad for it to do utf32->utf8 conversion. >> >> 2) Use -fshort-wchar only if CONFIG_EFI_LOADER=y.. UEFI only requires >> fat/vfat so we don't need ext4 and efi loader at the same time. >> >> 3) Go with Heinrich's suggestion of requiring c11. Possibly this >> requirement could be loosened to only require c11 for efi loader. >> This seems like the best approach, and at least no one has so >> far brought up any objection to his proposal. >> >> Not-signed-off-by: Rob Clark <robdcl...@gmail.com> > > Do I understand you right? > You do not want the current version of the patch series merged?
nope, I fully expect review comments and updates, hence calling it "v0".. I just don't want it to be ignored, as is the tendency for large RFC's on other lists that I am on. Hence the "Not-signed-off-by" ;-) > It might have been better to replace [PATCH] by [RFC] in the subject > lines of the patch set in this case. > > I am currently trying to find out if the switch to C11 is possible, cf. > https://travis-ci.org/xypron2/u-boot/builds/261098363. > > Unfortunately Travis uses gcc 4.8.2 for some jobs which does not yet > support C11. > > Furthermore there seems to be some problem in disk/part_efi.c with > PARTITION_SYSTEM_GUID. hmm, link/pastebin error, and I can have a look? On my wip branch that included this patchset, plus other bits needed to make it work on db410c, I didn't see any such issues, but I might have screwed something up in splitting up the db410c and related fixes from the efi_loader patchset. I do have some regressions on a couple of the vexpress boards, which are totally unrelated to the patch that introduces the regression and I cannot reproduce locally (although locally I have newer gcc and qemu). See [1] which is introduced by patch 15. I'm pretty sure this is a problem with the test environment (either gcc or qemu), but not quite sure what to do about it. [1] https://travis-ci.org/robclark/u-boot/jobs/260997492 BR, -R > Best regards > > Heinrich > >> --- >> config.mk | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/config.mk b/config.mk >> index b77d58903c..5ad9e7198d 100644 >> --- a/config.mk >> +++ b/config.mk >> @@ -74,7 +74,7 @@ endif >> RELFLAGS := $(PLATFORM_RELFLAGS) >> >> PLATFORM_CPPFLAGS += $(RELFLAGS) >> -PLATFORM_CPPFLAGS += -pipe >> +PLATFORM_CPPFLAGS += -pipe -fshort-wchar >> >> LDFLAGS += $(PLATFORM_LDFLAGS) >> LDFLAGS_FINAL += -Bstatic >> > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
