Bug 1215

Summary: Can't build minimal image with IMAGE_LINGUAS set
Product: [Build System, Metadata & Runtime] Meta-yocto Reporter: Gary Thomas <gary>
Component: meta-yoctoAssignee: Saul Wold <sgw>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: High CC: jiajun.xu, poky.bs.watcher, poky.watcher, sgw
Version: unspecified   
Target Milestone: 1.1 M2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---
Attachments:
Description Flags
Minimal image recipe none

Description Gary Thomas 2011-07-06 05:10:01 UTC 
If IMAGE_LINGUAS is set non-empty, building of minimal image will fail.
This is a recent regression - all of the core*minimal images force IMAGE_LINGUAS
to an empty set.  I have a minimal image which was based on core-image-minimal
from some time ago that does not manipulate IMAGE_LINGUAS which now fails.

Try this (from scratch):
  % bitbake my-min-image
will result in this error:
  | Processing locale-base-en-us...
  | Unable to find package locale-base-en-us!
  | ERROR: Function 'do_rootfs' failed (see /home/local/bb_latest/tmp/work/beagleboard-poky-linux-gnueabi/my-min-image-1.0-r0/temp/log.do_rootfs.30041 for further information)

Obviously, the internal rules associated with IMAGE_LINGUAS cause the locale-base-en-us package to be needed by the image, but these are not built by this image.  Building a more complicated image, e.g. core-image-sato, does properly build the locale-base-* packages.
Comment 1 Gary Thomas 2011-07-06 05:10:37 UTC 
Created attachment 184 [details]
Minimal image recipe
Comment 2 Richard Purdie 2011-07-06 05:55:42 UTC 
Once you've run "bitbake eligbc-locale", does this still happen?
Comment 3 Gary Thomas 2011-07-06 06:56:18 UTC 
Yes, it does build after building eglibc-locale

Perhaps there should be an explicit dependency on virtual/libc-locale?
Comment 4 Gary Thomas 2011-07-06 07:45:23 UTC 
BTW, why does it take so long to build eglibc-locale?
Using ipk:
  real    14m0.503s
  user    8m19.703s
  sys     4m19.037s
Using rpm:
  real    22m28.906s
  user    9m35.337s
  sys     12m8.473s

My build host is reasonably fast (Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz)
and I run with
  BB_NUMBER_THREADS = "4"
  PARALLEL_MAKE = "-j 4"
Comment 5 Gary Thomas 2011-07-06 08:23:23 UTC 
Note: when I added "libc-locale" to my image (since eglibc-locale is a virtual provider for this package), I get this error:

ERROR: Trying to resolve runtime dependency libc-locale resulted in conflicting PREFERRED_PROVIDER entries being found.
The providers found were: ['virtual:nativesdk:/tmp/poky-amltd/meta/recipes-core/eglibc/eglibc_2.13.bb', '/tmp/poky-amltd/meta/recipes-core/eglibc/eglibc_2.13.bb']
The PREFERRED_PROVIDER entries resulting in this conflict were: ['PREFERRED_PROVIDER_virtual/libc-nativesdk = eglibc-nativesdk', 'PREFERRED_PROVIDER_virtual/libc = eglibc']
NOTE: multiple providers are available for runtime libc-locale (eglibc, eglibc-nativesdk, glibc-nativesdk, glibc)
NOTE: consider defining a PREFERRED_PROVIDER entry to match libc-locale

I also tried adding
  PREFERRED_PROVIDER_virtual/libc-nativesdk ?= "eglibc-nativesdk"
  PREFERRED_PROVIDER_virtual/libc-locale ?= "eglibc-locale"
to my distro.conf - no improvement
Comment 6 Richard Purdie 2011-07-06 09:27:13 UTC 
libc-locals does the work that used to be done in libc's do_package so you'll see that is faster and this step now takes the time. This does mean the system can do various things in the meantime without waiting for that though.
Comment 7 Saul Wold 2011-07-06 17:39:48 UTC 
*** Bug 1216 has been marked as a duplicate of this bug. ***
Comment 8 Richard Purdie 2011-07-07 08:56:43 UTC 
-RDEPENDS += "${IMAGE_INSTALL}"
+RDEPENDS += "${IMAGE_INSTALL} ${LINGUAS_INSTALL}"

in image.bbclass could potentially fix this...
Comment 9 Gary Thomas 2011-07-07 09:19:33 UTC 
Looks like it works :-)  I tested it with IMAGE_LINGUAS set non-empty and eglibc-locale was needed.  It also works fine when IMAGE_LINGUAS is empty.
Comment 11 Gary Thomas 2011-07-10 05:48:56 UTC 
I thought this was fixed.  I had tested earlier in a tree which had been successfully built like this:
  * Build a minimal image
  * bitbake eglibc-locale -ccleansstate
  * Rebuild image without patch - fails
  * Rebuild image with patch - succeeds

Sadly, a build 100% from scratch, even with the patch still fails.
Comment 12 Gary Thomas 2011-07-10 06:09:34 UTC 
More about the failure - it seems to be looking for a file in the wrong place:
ERROR: Function 'do_install_locale' failed (see /home/local/map8100_poky/tmp/work/armv5te-amltd-linux-gnueabi/eglibc-2.13-r6+svnr14157/temp/log.do_install_locale.12171 for further information)
ERROR: Logfile of failure stored in: /home/local/map8100_poky/tmp/work/armv5te-amltd-linux-gnueabi/eglibc-2.13-r6+svnr14157/temp/log.do_install_locale.12171
Log data follows:
| mv: cannot stat `/home/local/map8100_poky/tmp/work/armv5te-amltd-linux-gnueabi/eglibc-2.13-r6+svnr14157/image/usr/bin/localedef': No such file or directory
| ERROR: Function 'do_install_locale' failed (see /home/local/map8100_poky/tmp/work/armv5te-amltd-linux-gnueabi/eglibc-2.13-r6+svnr14157/temp/log.do_install_locale.12171 for further information)

However, when I find a find for localedef in the tmp tree, I only find it at
/local/p60_latest/tmp/work/armv7a-amltd-linux-gnueabi/eglibc-2.13-r5+svnr14157/image/usr/include/eglibc-locale-internal-armv7a-amltd-linux-gnueabi/usr/bin/localedef

which I think is a rather strange place.
Comment 13 Gary Thomas 2011-07-10 16:40:57 UTC 
Sorry, this was operator error :-(  My build was missing ${DISTRO_FEATURES_LIBC} in DISTRO_FEATURES which caused these problems.  The build is working fine now.

Note: per bug #1212, messing up DISTRO_FEATURES, especially the DISTRO_FEATURES_LIBC functions, causes lots of errors, many hard to associate back to the source of misconfiguration.