[OE-core] [patch v2 1/1] bitbake.conf: fix rpath for sdk executables

[Richard Purdie]

On Fri, 2012-03-23 at 22:02 -0700, nitin.a.kamble at intel.com wrote:
> From: Nitin A Kamble <nitin.a.kamble at intel.com>
> 
> This makes the libraries located in places like this findable:
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib
> 
> Which avoids linking sdk executables with host libraries like this:
> 
> $ ldd /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
>         linux-vdso.so.1 =>  (0x00007fffb7fff000)
>         libreadline.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/x86_64-oe-linux/../libreadline.so.6 (0x00007fbfb5511000)
>         libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007fbfb530c000)
>         libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007fbfb50e9000)
>         libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007fbfb4ec2000)
>         libz.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/x86_64-oe-linux/../libz.so.1 (0x00007fbfb4cac000)
>         libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007fbfb4a2a000)
>         libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007fbfb480d000)
>         libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007fbfb4609000)
>         libexpat.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/x86_64-oe-linux/../libexpat.so.1 (0x00007fbfb43e0000)
>         libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007fbfb4059000)
>         /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003f05000000)
> 
> Signed-off-by: Nitin A Kamble <nitin.a.kamble at intel.com>
> ---
>  meta/conf/bitbake.conf |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 824ef04..50f0308 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -480,7 +480,9 @@ export BUILD_LDFLAGS = "-L${STAGING_LIBDIR_NATIVE} \
>  
>  BUILDSDK_LDFLAGS = "-L${STAGING_LIBDIR} \
>                      -Wl,-rpath-link,${STAGING_LIBDIR} \
> +                    -Wl,-rpath-link,${STAGING_LIBDIR}/.. \
>                      -Wl,-rpath,${libdir} -Wl,-O1 \
> +                    -Wl,-rpath,${libdir}/.. -Wl,-O1 \
>                      -L${STAGING_DIR_HOST}${base_libdir} \
>                      -Wl,-rpath-link,${STAGING_DIR_HOST}${base_libdir} \
>                      -Wl,-rpath,${base_libdir} -Wl,-O1"

>From the description above it took me a long time to realise what you're
referring to. The problem you're solving is specific to
cross-canadian.bbclass which changes libdir to include a suffix.

Please append your two entries to this variable within
cross-canadian.bbclass and then this makes a lot more sense! If you
don't it will lead to strange RPATHs in parts of the system.

Technically this change shouldn't be necessary since we'd use our own
dynamic loader within the SDK and it knows about the paths apart from
the one with the suffix. We likely could therefore remove some of this
but now isn't the time for that! If you used a cross-ldd for our SDK
toolchain, you'd should see something different to the above.

Cheers,

Richard