Re: relocate_sdk.py: Possible bug, /lib64/ld-linux-x86-64.so.2 not relocated

[Jason Wessel <jason.wessel@windriver.com>]

On 03/01/2014 08:26 AM, Stefan Agner wrote:
> Hi,
>
> Using top of dylan branch, I generated a SDK using bitbake
> meta-toolchain. I'm running Arch Linux, but I also see similar issues on
> Ubuntu 12.04.4 LTS:
>
> Some binaries segfault when running them. I discovered, that the dynamic
> linker of the host is used:
> $ ldd
> /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
> linux-vdso.so.1 (0x00007fffc8f11000)
> libc.so.6 =>
> /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/../../../lib/libc.so.6
> (0x00007f4d85eb1000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f4d8625f000)
>
> When forcing the dynamic linker of the SDK, the binary works:
> $
> /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-linux-x86-64.so.2
> /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
> arm-angstrom-linux-gnueabi-gcc: fatal error: no input files
> compilation terminated.
>
> Digging around I found this commit by Jason:
> 3752a9c6d772b39bbe04d62ef4d3527b4c7198c1
> relocate_sdk.py: Fix corruption of sdk binaries
>
> It changes the behavior and don't relocates stuff which start with
> /lib64. When I install the SDK with -S (copy the relocate scripts), and
> remove the condition around line 95, the binaries work as expected. Also
> LDD shows that ld-linux-x86-64.so.2 of the SDK will be used.
>
> Btw, I think this bug is related to that:
> https://github.com/Angstrom-distribution/setup-scripts/issues/25
>
> Since I don't understand the original intention of that commit, I'm not
> sure how to fix this properly...

My guess is that the compiler recipe is not using the right linker.  The change to ignore binaries that are linked against the host libc is there intentionally.  We don't want to relocate binaries that are for a specific host or set of hosts.  The main reason it is there is to allow for the inclusion of binaries that were generated by the SDK as well as binaries that came from outside the SDK.

When you use the host's ld to link something and end up linking against the host's linux-vdso.so.1 there is not enough space for the path relocations.  The proper fix should be to ensure the recipe that builds your compiler has the same patches and linking of binaries as the oe-core cross compiler.

Cheers,
Jason.