On 8/11/16 2:14 PM, Burton, Ross wrote: > > On 11 August 2016 at 18:11, Mark Hatle <[email protected] > <mailto:[email protected]>> wrote: > > Binary locales have an endian and alignment setting to them. If a > platform > supports both big and little endian, this common locale would not work. > (That > is extremely rare....) Also if a platform supports different alignments > in > different libraries that could cause an impact as well. (This is also > extremely > unlikely.) > > > So by that logic this patch should be rejected, right?
The binary bits was why it was not originally implemented this way. HOWEVER, are there are conflicting cases we have to worry about for the binaries? If there are not any reasonable cases -- then this may save a huge amount of space for a device that contains a number of binary locales. (In otherwords, I don't object to the patch due to those reasons -- I just want it to be clear to folks that there are binary nuances to this, it is extremely rare that it's a problem, so rare it may simply NOT be an issue in our configuration. But these can never be 'noarch' packages as they are tied to an arch.) --Mark > This path is for the compiled locale definitions - LC_TYPE etc and the locale > archive, right? So it's only glibc-locales that ships in here, not other > packages (just trying to check my assumptions) > > Ross -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
