[v2,1/1] bitbake.conf: fix rpath for sdk executables

Submitted by Nitin A Kamble on March 24, 2012, 5:02 a.m.

Details

Message ID 3050966a33b84230c8787d4782cd9c2c80f0a5a6.1332565237.git.nitin.a.kamble@intel.com
State New
Headers show

Commit Message

Nitin A Kamble March 24, 2012, 5:02 a.m.
From: Nitin A Kamble <nitin.a.kamble@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@intel.com>
---
 meta/conf/bitbake.conf |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Patch hide | download patch | download mbox

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"

Comments

Richard Purdie March 24, 2012, 10:15 a.m.
On Fri, 2012-03-23 at 22:02 -0700, nitin.a.kamble@intel.com wrote:
> From: Nitin A Kamble <nitin.a.kamble@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@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