1. posterid:3616708
  2. Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

Re: Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

Bryan Evenson
 

Ross,

 

 

From: Burton, Ross [mailto:ross.burton@...]
Sent: Tuesday, September 26, 2017 3:13 PM
To: Bryan Evenson <bevenson@...>
Cc: yocto@...
Subject: Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)

 

Hi,

 

On 26 September 2017 at 18:16, Bryan Evenson <bevenson@...> wrote:

  WARNING: The Linux kernel on your build host was not configured to provide process I/O statistics. (CONFIG_TASK_IO_ACCOUNTING is not set)

I searched the Yocto Project documentation and I couldn't figure out what specifically these I/O statistics are used for.  What affect does this have on my build?  Does anybody know if there is a way to enable I/O statistics for the WSL?

 

That's the buildstats class that is enabled in your local.conf.  I don't expect WSL will ever fake a Linux-compatible /proc directory structure, so you can just disable this.

 

OK.  I removed that from my local.conf and the warning went away.

 

 

I'm also seeing a very slow refresh of the build status on the command line.  When multiple tasks are running, I can see the lines clear away from the bottom of the screen to the top and then fill in back down.  The resulting flash from the refresh makes it nearly impossible to read what some of the running tasks are.  What is the actual mechanism for updating the task status on the command line?  I'm wondering if it's counting on some feature that Microsoft hasn't fully supported yet.

 

This is just standard curses, so you'll have to wait for Microsoft to make it faster.

 

If you do "bitbake <your targets> | cat" then bitbake will fall back to a UI that isn't interactive and will be a lot faster.

 

After I disabled buildstats, the refresh noticeably improved.  From looking at buildstats.bbclass, I see a number of ‘stat’ calls.  I’m guessing the stat call has some efficiency improvements left to go on WSL.

 

I am also getting a build error with glibc-locale.  In the do_package stage I'm getting a failure in the function sstate_task_postfunc.  The error is on the following command:

  cp -afl --preserve=xattr <base_path>/poky/poky-build/tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/packages-split/* <base_path>/poky/poky-build/tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/sstate-build-package//packages-split/*

I am seeing a lot of errors from this command that look like the following:

 cp: cannot create hard link: '<base_path>/poky/poky-build/tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/sstate-build-package//packages-split/glibc-binary-localedata-ks-in/usr/lib/locale/ks_IN/LC_MEASUREMENT' to '<base_path>/poky/poky-build/tmp/work/armv5e-poky-linux-gnueabi/glibc-locale/2.24-r0/packages-split/glibc-binary-localedata-ks-in/usr/lib/locale/ks_IN/LC_MEASUREMENT': Invalid argument

I looked at my working directory, and I see that in the source files are there.  If I run the cp command from the command line as shown above, I get the same errors.  I'm trying to figure out if this is an issue with hard links with WSL or if this is general build issue.  Any suggestions on what else to try?

 

Now this *is* interesting.  Try removing the repeated slashes just in case the WSL ln is being incredibly pedantic (ie sstate-build-package//packages-split), but I don't seriously expect that to be the problem.  Running stat on the source and verifying the destination doesn't exist would be helpful.  Can you tell if that is the first ln that it is trying to do, or do many work and that one fails?  Does WSL have a working strace or similar to identify which exact syscall is failing?

 

I am about 60% through the full image build when it gets to glibc-locale with about half of the packages for the image fully complete.  I did a stat on one of the source files and verified it did exist, and it had 0644 for access rights and is owned by me.  I also verified that the destination file doesn’t exist.  WSL does have a working strace.  I ran strace on the failed cp command shown above and I now have a 56MB strace output file.  What should I be looking for in this file?

 

In all honestly I'm surprised you got the build to go as far as you have under WSL, that's impressive.  Have you been able to compare performance against a full VM on the same hardware?

 

I haven’t got far enough to do a good performance comparison.  Overall performance seems similar, maybe a little slower than against a full VM.

 

Ross
Join yocto@lists.yoctoproject.org to automatically receive all group messages.