Building SHR manually from scratch

The following commands will start a build of shr-core, without a chroot environment. For the "conventional" chroot approach see below section.

EDITOR=emacs

git clone http://git.shr-project.org/repo/shr-makefile.git common

git clone git://git.openembedded.org/openembedded-core-contrib openembedded-core
cd openembedded-core
git checkout shr
cd ..

git clone git://git.openembedded.org/meta-openembedded-contrib meta-openembedded
cd meta-openembedded
git checkout shr
cd ..

git clone git://git.shr-project.org/meta-smartphone.git meta-smartphone
cd meta-smartphone
git checkout shr
cd ..

git clone git://github.com/OSSystems/meta-mozilla.git

git clone git://git.openembedded.org/bitbake bitbake

mkdir downloads
mkdir shr-core
cd shr-core


ln -s ../openembedded-core .
ln -s ../meta-openembedded .
ln -s ../meta-smartphone .
ln -s ../meta-mozilla .
ln -s ../bitbake .
ln -s ../downloads .
ln -s ../common/setup-env .
ln -s ../common/setup-local .


echo 'export BBFETCH2=True' >> setup-local
cp -ra ../common/conf/shr-core conf
echo "TOPDIR='`pwd`'" > conf/topdir.conf
$EDITOR conf/local.conf
# Set machine appropriately
$EDITOR setup-local

. setup-env
bitbake -k shr-image

It is not necessary to build or install bitbake from the cloned tree; the environment setup scripts adjust the PATH to refer to the cloned tree, which contains executables as-is (ie, python scripts). The latest git bitbake is required for building shr-core.

After building, images should be deposited in tmp-eglibc/deploy/images/.

Building SHR using Makefile

How to setup a local SHR repository and build images automatically using SHR Makefile.

Install required dependencies

To run bitbake (make image) some programs are needed to be installed on the buildhost:

libtool, python-2.6, git, svn, cvs, make, gcc, g++, patch, help2man, diffstat, texi2html, bzip2, gawk, tar, md5sum, texinfo, chrpath

Install required packages on ubuntu oneiric (may as well work on debian)

# apt-get install build-essential coreutils libtool python2.6 git git-core subversion cvs make gcc g++ patch help2man diffstat texi2html bzip2 gawk tar texinfo chrpath

bash must be your default shell. On Ubuntu dash is used by default and can be changed to bash using

# dpkg-reconfigure dash
chose no.

Getting Makefile

Download the FSO/SHR Makefile from  shr-project (see README for details):

$ wget http://build.shr-project.org/Makefile

You can build SHR images on almost any GNU/Linux distribution you already have installed or you can use provided minimal chroot environment to minimize influence of your host system and this chroot is what most SHR users use, so it's well tested.

To setup shr-chroot :

$ # be aware that 64bit version is used by most SHR devs so it's updated more often and better tested
$
$ # for 64bit systems run:
$ make setup-shr-chroot
$
$ # for 32bit systems run:
$ make setup-shr-chroot-32bit

make setup-shr-chroot will checkout shr-chroot repository to shr-chroot directory (mostly git downloading data, so network-bound). And it will also change UID/GID of included bitbake account from default 1026 to UID/GID of user who called setup-shr-chroot. Then you need root to be able to bind important system directories to it and then change / to it.

$ cd shr-chroot
$ sudo ./shr-chroot.sh

Now you don't need root anymore, so switch to prepared bitbake account and setup preferred shr version.

$ su - bitbake
$ make setup-shr-core # for up-to-date code. #or for 'in some days deprecated' code "make setup-shr-unstable" or "setup-shr-testing"

This will checkout common directory with shared config files and Makefile, openembedded directory with OE and shr-unstable directory. You need to do this step even if you have old shr-unstable builddir to get new config files!

You are nearly ready to build your first image. But before you can tweak some configurations files, see next section.

Configuration

local.conf is a central configuration file in your openembedded/shr/yocto/etc. tree. It's located at

shr-unstable/conf/local.conf or shr-testing/conf/local.conf

Although it should be setup already when using Makefile, you might want to make a few teaks:

Make use of multiple CPUs

PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Disable / Minimize locales generation

To avoid multiple locales generation, add:

GLIBC_GENERATE_LOCALES = "en_US.UTF-8 en_GB.UTF-8 cs_CZ.UTF-8"

and you also need to set IMAGE_LINGUAS accordingly

IMAGE_LINGUAS = "en-us en-gb cs-cz"

or to disable locale generation at all (You can't build an shr image without the en_US.UTF-8 locale, so this is only for building single packages):

ENABLE_BINARY_LOCALE_GENERATION = "0"

this will also speed up the whole build.

shr-testing and shr-unstable require a diffeernt bitbake version

The default version of bitbake is the most recent one and is needed for shr-core. To build shr-testing or shr-unstable, you must switch to bitbake version 1.12 first.

$ cd /OE
$ make setup-bitbake
$ mv bitbake shr-unstable/ # or shr-testing/
$ cd shr-unstable/bitbake  # or shr-testing/bitbake
$ git checkout 1.12
$ cd /OE

switching can also be done by make update:

make BITBAKE_VERSION=1.12 update # switches to bitbake 1.12
make update # switches back to most recent version 'master'

Building

Chosing a target machine

SHR Makefile sets the enviornment up to build for the OM-GTA02 device. To compile for other devices you can prefix MACHINE before bitbake command:

MACHINE=om-gta01 bitbakeb shr-image # for n900 use MACHINE=nokia900, a full list of supported devices can be found at ...

Or you can change it in setup-local (and run ". ./setup-env" again).

General build process

For each build terminal session this must be ran:

sudo shr-chroot.sh  #---> enter the chroot
su - bitbake        #---> change to bitbake user
cd shr-unstable     #---> to build unstable packages
. ./setup-env       #---> Set build env
bitbake -k <packaganame> # example package names: shr-image shr-lite-image etc. # the -k parameter causes bitbake to continue on failed dependencies. recommended for packages with large dependency trees like images.

Completed images are saved in shr-unstable/tmp/deploy/images, individual packages in shr-unstable/tmp/deploy/ipk/.

Check out the Troubleshooting section if you run into trouble.

For people coming from the old building process (i.e before the existence of shr-chroot) don't forget to take a look at the migration of old data section below in this page.

Building all SHR packges

If you want to build everything that is available in the shr feeds run the following:

bitbake -k task-shr-feed

Updating the local metadata

It is important to leave shr-chroot before updating it, so quit the shell and make sure that every binded directory is umounted:

For the 64-bit environment:

$ cd shr-chroot/OE
$ make update-shr-chroot

For the 32-bit environment:

$ cd shr-chroot-32bit/OE
$ make update-shr-chroot-32bit

Be aware that "make update-shr-chroot" will always revert your local changes. After updating to clean chroot it will reset UID/GID for bitbake user again.

Track and browse remote metadata on the web

SHR activity:

•  http://cgit.openembedded.org/openembedded/log/ to see what changes in OpenEmbedded;
•  http://git.shr-project.org/git/ to follow SHR applications improvements.

SHR-CORE activity:

•  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=shr
•  http://cgit.openembedded.org/meta-openembedded-contrib/log/?h=shr
•  http://git.shr-project.org/git/?p=meta-smartphone.git;a=summary

Development

If you are interested in developing SHR application, you should now switch over to Getting started developing SHR

Making changes

TODO: fix better

The below mentioned shr-dialer is now part of phoneui-apps, so you can run

bitbake phoneui-apps

Make changes to an SHR project (e.g. libphone-ui-shr):

Activate local builds: for this you have to uncomment the following line in shr-unstable/conf/local.conf:

#require local-builds.inc

Check out the sources of shr-dialer to a directory of your choice (e.g. ~/git):

git clone http://git.shr-project.org/repo/libphone-ui-shr.git

Update sample in shr-unstable/conf/local-builds.inc to point to right directory:

S_pn-libphone-ui-shr = "/path/to/source/${PN}" # update this!

Now start building the package to verify that you have a correct base version and a working development environment:

$ cd shr-unstable
$ . ./setup-env                      # only once per session
$ bitbake -c clean libphone-ui-shr
$ bitbake libphone-ui-shr

If something fails check the logfiles shr-unstable/tmp/work/armv4t-oe-linux-gnuabi/libphone-ui-shr-.0.0.0+gitrLOCAL-r*/temp. Do make your changes in your base directory, not in the temp working directories they might get lost, and then clean/build.

There is no need to check-in the changes to the SHR repo, because the system now looks for SHR packages in the local filesystem. The problem is that it is necessary to always clean the packages so bitbake gets the new changes next time you compile, or change the SRCREV to a higher version.

If the scanning of all the bitbake recipes is too slow for you use the interactive mode:

$ cd shr-unstable
$ . ./setup-env                      # only once per session
$ bitbake -i
BB>>rebuild libphone-ui-shr

Bitbake rebuild does both a compile and package build (but clean is needed when updating patches applied in SRC_URI), all other steps can also be run individually from the prompt.

Help improving shr-chroot

If you are interested in developing for FSO, the framework used by SHR, you should now switch over to Developing for FSO with shr-chroot

Updating from other people's changes

If you want to update everything (SHR-unstable, SHR-testing and bitbake), from the top directory:

$ make update

Or for just shr-unstable, from the top directory:

$ make update-shr-unstable

Or under the shr-unstable/openembedded directory:

$ git pull --rebase

Be aware that "make update*" will always revert your local changes to repo. If you want to keep them, then better to call "git pull --rebase" manually.

Migrate old data/builds to shr-chroot environment

Reuse old checkout/downloads if you have them already on disk:

cp -ra ../openembedded shr-chroot/OE
cp -ra ../downloads shr-chroot/OE

You can migrate old builddir (in case you don't want to rebuild from scratch), but I strongly recommend to rebuild from scratch if your tmpdir wasn't in path /OE/shr-unstable/tmp before. For rebuild from scratch you could still migrate old cache directory to have upgradeable path.

exit; #to chrooted root
exit; #to root in normal /
exit; #to normal user
cd .. #to directory above shr-chroot

cp -ra ../shr-unstable/tmp shr-chroot/OE/shr-unstable/tmp
# migrate to per-machine cache (LOCALCOUNT numbers etc), this step is needed if you want to preserve upgradeable path from old image.
echo "/OE/shr-unstable/tmp" >> shr-chroot/OE/shr-unstable/tmp/saved_tmpdir # update saved_tmpdir if needed to new location, very tricky, stuff can fall apart, better to rebuild from scratch

su
./shr-chroot.sh

Recreate config files

Configuration files ie in shr-unstable/conf are not updated after initial setup-shr-unstable. If you want to refresh them with current version.

mv shr-unstable/conf shr-unstable/conf-old
rm -f shr-unstable/.configured
make setup-shr-unstable
# check diff
diff -rq shr-unstable/conf-old shr-unstable/conf

Troubleshooting

/etc/network/interfaces (usb0 not comming up)

bitbake -c cleansstate netbase
bitbake -k shr-image

initscripts/initscripts-shr issues in shr-core

initscripts-shr files were replaced with bunch of .bbappends to default initscripts to get all the fixes from upstream initscripts automaticaly  http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=a3996a020a423e9cf1252ea1028d25d160b21500 after this commit you have to rebuild keymaps and task-core-boot and to be sure it's better to remove cache first (I had problem that task-core-boot were still depending on initscripts-shr instead of initscripts).

rm -rf tmp/cache/bb_codeparser.dat*
rm -rf tmp/cache/default-eglibc/
bitbake -c cleansstate task-core-boot keymaps
bitbake -k shr-image

and to fix it on target (phone)

opkg install -force-reinstall keymaps task-core-boot; opkg remove initscripts-shr; opkg install initscripts

Cannot parse recipes or do_rootfs after openssl upgrade

openssl was upgraded  http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=5050e12ca809ee54dd25d1b6ed83a7eea3c3bf14 If you notice errors like this

| ERROR: Function 'Fetcher failure for URL: 'git://git.freesmartphone.org/cornucopia;protocol=git;branch=master'. Unable to fetch URL git://git.freesmartphone.org/cornucopia;protocol=git;branch=master from any source.' failed
| git: /var/lib/jenkins/jobs/shr-core-clean-build2/workspace/shr-core/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libcrypto.so.1.0.0: version `OPENSSL_0.9.8' not found (required by git)
|  git: /var/lib/jenkins/jobs/shr-core-clean-build2/workspace/shr-core/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libcrypto.so.1.0.0: version `OPENSSL_0.9.8' not found (required by git)

or while doing rootfs

| Collected errors:
|  * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-shr-minimal-fso:
|  *    libcrypto0.9.8 (>= 0.9.8m) *    libssl0.9.8 (>= 0.9.8m) *       libcrypto0.9.8 (>= 0.9.8m) *
|  * opkg_install_cmd: Cannot install package task-shr-minimal-fso.
|  * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-core-ssh-openssh:
|  *    libcrypto0.9.8 (>= 0.9.8m) *    libcrypto0.9.8 (>= 0.9.8m) *    libcrypto0.9.8 (>= 0.9.8m) *
|  * opkg_install_cmd: Cannot install package task-core-ssh-openssh.
|  * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-shr-cli:
|  *    libcrypto0.9.8 (>= 0.9.8m) *    libssl0.9.8 (>= 0.9.8m) *       libssl0.9.8 (>= 0.9.8m) *       libcrypto0.9.8 (>= 0.9.8m) *    libcrypto0.9.8 (>= 0.9.8m) *    libssl0.9.8 (>= 0.9.8m) *       libcrypto0.9.8 (>= 0.9.8m) *
|  * opkg_install_cmd: Cannot install package task-shr-cli.
| ERROR: Function 'do_rootfs' failed (see /OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/shr-image-2.0-r18/temp/log.do_rootfs.8138 for further information)

then you have to rebuild few packages:

bitbake -c cleansstate -b virtual:native:openembedded-core/meta/recipes-devtools/git/git_1.7.5.1.bb
bitbake -b virtual:native:openembedded-core/meta/recipes-devtools/git/git_1.7.5.1.bb
bitbake -c cleansstate python-native syslog-ng socat python openssh mbuffer openvpn dhcp bind
bitbake -k shr-image

Bitbake errors seting a SemLock on some amd64 wheezy

This is caused by  isue3311 a workarround is to mount a tmpfs on /dev/shm inside the chroot see also  Bug#410154: checking /dev/shm inside a chroot

mount none -t tmpfs /dev/shm 
su - bitbake

Bitbake general troubleshoting Tip

For shr-core use shr-chroot bitbake as it is more tested for shr than a current master/origin and if is there any issues it is usually fixed on shr-chroot first.

To activate shr-chroot bitbake on shr-core just remove the link to bitbake dir and re-source setup-env:

OE @ ~/shr-core $ rm bitbake
OE @ ~/shr-core $ . setup-env 
Altered environment for om-gta02@shr development

Unset variables

One thing to try is to unset all environment variables not listed in this page. LIBPATH and INCLUDE can be particularly troublesome.

vala

Note: Unless you have valac on your build box, you're bound to run into trouble with vala-native. To work around this, do: bitbake -c clean vala-bootstrap-native; bitbake vala-bootstrap-native. Then vala-native should bitbake ok, allowing image to be built.

(btw. if you bitbake vala-native and you want to bitbake it again, you have to explicitly clean and rebake vala-bootstrap-native)

missing dependency

Note: it's highly probable that the build will fail due to a missing dependency, fso-abyss: you will have to execute "bitbake fso-abyss" manually inside the shr-unstable folder in order to get it built, and retry the image building.

Please set the 'CACHE' variable

If you get the error 'Please set the 'CACHE' variable', then you've probably forgot to run ". ./setup-env" in your current shell.

shasum-native

If build fails on "openembedded/packages/shasum/shasum-native.bb, do_compile" with empty log and you aren't using debian it's probably 'ccache' fault. Try one of these:

$ echo 'export HOME = "'$HOME'"' >> openembedded/conf/bitbake.conf 
$ echo 'CCACHE = ""' >> conf/local.conf

error: C preprocessor arm-angstrom-linux-gnueabi-gcc -E fails sanity check

If build fails on "do_configure" with "configure: error: C preprocessor arm-angstrom-linux-gnueabi-gcc -E fails sanity check", run:

$ bitbake -c clean gcc-cross-initial gcc-cross-intermediate gcc-cross gcc gcc-cross-sdk binutils-cross binutils binutils-cross-sdk eglibc-initial eglibc && bitbake eglibc

Can't locate ExtUtils/MakeMaker?.pm

If build fails on git-native with "Can't locate ExtUtils/MakeMaker?.pm ..." in the Log, you need to install the package "perl-ExtUtils?-MakeMaker?" on your buildhost.

libtool-native

If libtool-native fails in do_compile with: "source directory already configured": The cause can be a symlink in your TOPDIR variable (this then propagates to OE) - check conf/topdir.conf.

gst-plugins-good fails

Open openembedded/recipes/gstreamer/gst-plugins-good_0.10.17.bb add to EXTRA_OECONF --disable-esd Terminal: . ./setup-env bitbake -c configure gst-plugins-good bitbake -c rebuild gst-plugins-good make image

fso-specs

If build fails with "..../fso-specs_git.bb do_compile failed" check whether xsltproc is installed. In ubuntu it can be installed via:

$ sudo apt-get install xsltproc

/usr/bin/ld: cannot find -lc

If build fails on module-init-tools-cross with "/usr/bin/ld: cannot find -lc" check whether you have libc static library installed. In Debian/Ubuntu? libc6-dev package should provide it. In Fedora, install glibc-static package.

libgee: do_configure fails

since 2010-10-17 06:52:41 libgee configure will NOT use its own libtool macros. So it needs a native libtool installed on your build host.

install libtool (eg: Ubuntu /Debian):

apt-get install libtool

and then build again

. ./setup-env
bitbake -c clean libgee
make image

git-native in shr-core, checkout from  http:// git transport

git-native is broken when using rm_work  http://lists.linuxtogo.org/pipermail/openembedded-core/2011-April/001313.html other workarround is to

bitbake -c clean git-native
rm -rf sstate-cache/sstate-git-native-x86*
bitbake -c build git-native # to preserve work dir
mv tmp/work/x86*/git-native* .
bitbake git-native  # to finish rm_work for git-native
cp -ra git-native* tmp/work/x86* #return it back and keep copy

and you also have to rebuild git-native after blacklisting libiconv-native in  http://git.shr-project.org/git/?p=meta-shr.git;a=commit;h=635986721577e42475e24de105776e1a23ed5646

gdk-pixbuf missing in shr-core do_rootfs

 http://git.shr-project.org/git/?p=meta-shr.git;a=commit;h=635986721577e42475e24de105776e1a23ed5646 blacklisted gdk-pixbuf few recipes need to be rebuild

rm -rf sstate-cache/sstate-gdk-pixbuf-armv*
rm -rf sstate-cache/sstate-gtk+-*
rm -rf sstate-cache/sstate-evas-*
rm -rf sstate-cache/sstate-gconf-*
rm -rf sstate-cache/sstate-librsvg-armv*
rm -rf sstate-cache/sstate-poppler-*
rm -rf sstate-cache/sstate-libglade-*
rm -rf sstate-cache/sstate-matchbox-panel-2-armv*
rm -rf sstate-cache/sstate-vte-*
rm -rf sstate-cache/sstate-libcanberra-*
bitbake -c clean gdk-pixbuf gtk+ evas gconf librsvg poppler libglade matchbox-panel-2 vte libcanberra
bitbake -k shr-lite-image

rebuilding from scratch

to completely rebuild everything from scratch, remove everything except cache/ from shr-unstable/tmp/

cd shr-unstable/tmp/
ls | grep -v cache | xargs rm -rf

ffmpeg and libav

Indication of this error: "final link failed: Nonrepresentable section on output"

apply this patch from Martin Jansa before you build () ref:  http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-March/030534.html ref:  http://patches.openembedded.org/patch/935/

cd shr-unstable/openembedded
contrib/patchwork/pw-am.sh 935

subversion 1.7 in shr-chroot

subversion was upgraded to 1.7 in shr-chroot, so also SHR buildhost is using that  http://git.shr-project.org/git/?p=shr-chroot.git;a=commit;h=c6969ca5d1a1406e94a2b908f6e06af5612ee3dc

be aware of svn-1.7 which needs you to upgrade manually your local
  checkouts or do_fetch will fail with something like this:
  WARNING: Fetcher failure for URL: 'None'. Fetch command export HOME="/OE"; export GIT_CONFIG="/OE/shr-core/tmp/sysroots/x86_64-linux/usr/etc/gitconfig"; export PATH="/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/armv4t-linux:/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin:/OE/shr-core/tmp/sysroots/x86_64-linux/usr/sbin:/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin:/OE/shr-core/tmp/sysroots/x86_64-linux/sbin:/OE/shr-core/tmp/sysroots/x86_64-linux//bin:/OE/shr-core/openembedded-core/scripts/native-intercept:/OE/shr-core/openembedded-core/scripts:/OE/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.1:/OE/shr-core/openembedded-core/scripts/:/OE/shr-core/openembedded-core/scripts"; /usr/bin/env svn update -r 64050 failed with signal 1, output:
  svn: E155036: Please see the 'svn upgrade' command
  svn: E155036: Working copy '/OE/downloads/svn/svn.enlightenment.org/svn/e/trunk/ecore' is too old (format 10, created by Subversion 1.6)

  to fix your local checkouts you can do:
  cd /OE/downloads/svn/; for repo in `find . -name .svn`; do cd ${repo}/..; svn upgrade; cd /OE/downloads/svn/; done | tee svn.upgrade.log

  you can ignore errors like this:
  bash: cd: ./svn.enlightenment.org/svn/e/trunk/eeze/doc/img/.svn/..: No such file or directory
  svn: E155019: Can't upgrade '/OE/downloads/svn' as it is not a pre-1.7 working copy directory
  when the .svn dir is already gone from svn upgrade in upper level

  or
  svn: E155019: Can't upgrade '/OE/downloads/svn/svn.o-hand.com/repos/misc/trunk/zaurusd' as it is not a pre-1.7 working copy directory
  svn: E150000: Missing default entry
  if it tries to upgrade checkout already upgraded or checkouted with 1.7

if you're not using shr-chroot and have older subversion than 1.7 you can get oposite error about checkout created by newer subversion than you have, this happens only when ie you change SRCREV without own checkout in downloads/svn and bitbake downloads tarballed svn repository from SHR buildhost (created with 1.7) and then it tries to svn upgrade to requested revision. In such case upgrade your subversion or do checkout in downloads/svn with your version.

Or now you can bitbake subversion-native before building elementary (or better as soon as possible).

Manual fix needed after perl/perl-native upgrade

In order to get builds running again you have to manually clean stuff which is installed in /usr/lib/perl/old_version. Normally it would be resolved by PR bump in those recipes, but oe-core wants automagic PR bumps instead and doesn't care about upgradepaths or continual builds.

Ie now there was perl upgrade from 5.12.3 to 5.14.2, so you have to cleansstate everything you'll find in

tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.12.3/

tmp/sysroots/*/usr/lib/perl/5.12.3

Here it was this:

bitbake -c cleansstate libxml-parser-perl-native libxml-simple-perl-native expat-native sgmlspl-native git-native

but you can have more stuff there..

libstdc++.so.6 issues

If you see something like

| gperf: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

or similar from cmake apod, try

OE @ ~ $ ldd shr-core/tmp/sysroots/x86_64-linux/usr/bin/cmake
        linux-vdso.so.1 =>  (0x00007fff28bff000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f4f4b8ed000)
        libstdc++.so.6 => not found
        libm.so.6 => /lib64/libm.so.6 (0x00007f4f4b66b000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4f4b455000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4f4b0ca000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4f4baf1000)
OE @ ~ $ touch /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/libstdc++.so.6
OE @ ~ $ /sbin/ldconfig
OE @ ~ $ ldd shr-core/tmp/sysroots/x86_64-linux/usr/bin/cmakec++.so.6
        linux-vdso.so.1 =>  (0x00007fffb09ff000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fe92416f000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/libstdc++.so.6 (0x00007fe923e37000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fe923bb5000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe92399f000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fe923614000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe924373000)

It happens when you build from scratch, some recipe build is messing with system's /etc/ld.so.cache and because with shr-chroot this file is owned by same user as user running builds (bitbake) then it succeeds.