[OE-core] [PATCH 3/3] glibc/glibc-locale: Fix do_stash_locale to work with usrmerge and multilibs

Jason Wessel jason.wessel at windriver.com
Thu Jul 4 11:57:50 UTC 2019


On 7/4/19 5:57 AM, Adrian Bunk wrote:
> On Thu, Jul 04, 2019 at 11:13:18AM +0200, Martin Jansa wrote:
>> I don't see how this change (or the previous glibc-locale one) would cause
>> that, but since the oe-core upgrade yesterday I'm seeing following
>> glibc-locale.do_package failure:
>> http://errors.yoctoproject.org/Errors/Details/250557/
>>
>> DEBUG: Executing shell function do_prep_locale_tree
>> tar: i18n: Cannot stat: No such file or directory
>> tar: Exiting with failure status due to previous errors
>> gzip:
>> TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/locale-tree//usr/share/i18n/charmaps/*gz.gz:
>> No such file or directory
>> WARNING:
>> TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/temp/run.do_prep_locale_tree.23303:1
>> exit 1 from 'gunzip $i'
>>
>> anyone else seeing this?
> 
> Yes.
> 


I don't know that it was specifically this change that causes the problem but rather any change to this function.   If that is not the case can either of you send me your local.conf file, and I'll try to reproduce it.  If the following doesn't work around the problem, there is clearly another corner case that is not well understood.

bitbake -c cleansstate glibc glibc-locale

I believe that any change to the .inc file which has locale stash function will cause the problem due to the fact it performs and "mv" operation to move the files.  When it runs a second time, there are no more files to move and you will not have them for use later on.  When I was experimenting earlier, I tried running the glibc temp/run.do_install script to put the files back, but then hit a problem with localdef being missing, because it comes from the temp/run.do_compile functions.

My conclusion thus far has been is that the ties between the glibc and glibc-locale are very subtle and break easily.  This is a separate problem than what I was attempting to fix, where the usrmerge + multilibs didn't even get the correct files in the first place.

Cheers,

Jason.


More information about the Openembedded-core mailing list