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

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

[Stefan Agner]

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...

--
Stefan

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

[Laurentiu Palcu]

Hi Stefan,

On Sat, Mar 01, 2014 at 03:28:09PM +0100, 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.
This is the correct behavior. We shouldn't relocate binaries that use
host's dynamic loader.

> When I install the SDK with -S (copy the relocate scripts), and
> remove the condition around line 95, the binaries work as expected. 
Can you please run the installer script with "-R" so it doesn't perform
any relocation on binaries, and then:

readelf -p ".interp" /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc

It looks like the default dynamic loader path of the toolchain binaries
start with /lib* or /usr/lib* which is not quite right... It should be:
${SDKPATH}/sysroots/${SDK_SYS}.

laurentiu

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

[Jason Wessel]

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.

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

[Stefan Agner]

Hi Laurentiu,

Am 2014-03-03 09:38, schrieb Laurentiu Palcu:
> This is the correct behavior. We shouldn't relocate binaries that use
> host's dynamic loader.
> 
>> When I install the SDK with -S (copy the relocate scripts), and
>> remove the condition around line 95, the binaries work as expected.
> Can you please run the installer script with "-R" so it doesn't perform
> any relocation on binaries, and then:
> 
> readelf -p ".interp"
> /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
> 
> It looks like the default dynamic loader path of the toolchain binaries
> start with /lib* or /usr/lib* which is not quite right... It should be:
> ${SDKPATH}/sysroots/${SDK_SYS}.

$ readelf -p ".interp"
/usr/local/oecore-x86_64-non-reloc/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc

String dump of section '.interp':
  [     0]  /lib64/ld-linux-x86-64.so.2


So this looks wrong then, right? 

I also get the same for python and qmake:
$ readelf -p ".interp" 
/usr/local/oecore-x86_64-new/sysroots/x86_64-angstromsdk-linux/usr/bin/python2

String dump of section '.interp':
  [     0]  /lib64/ld-linux-x86-64.so.2

$ readelf -p ".interp" 
/usr/local/oecore-x86_64-new/sysroots/x86_64-angstromsdk-linux/usr/bin/qmake2


String dump of section '.interp':
  [     0]  /lib64/ld-linux-x86-64.so.2

How can I make sure all those binaries get linked against the SDK link
loader?

--
Stefan

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

[Laurentiu Palcu]

Hi Stefan,

Can you please have a look at the binaries before relocation? Just to
make sure...

So, for that, run the installer with -R option:

./your_toolchain_installer.sh -R

Here, I'm interested which is the default suggested path (see below):

Enter target directory for SDK (default: /opt/poky/1.5+snapshot):

Then, run 'readelf -p ".interp"' on those binaries. They should all start
with the "default" prefix.

laurentiu


On Thu, Apr 03, 2014 at 09:59:34AM +0200, Stefan Agner wrote:
> Hi Laurentiu,
> 
> Am 2014-03-03 09:38, schrieb Laurentiu Palcu:
> > This is the correct behavior. We shouldn't relocate binaries that use
> > host's dynamic loader.
> > 
> >> When I install the SDK with -S (copy the relocate scripts), and
> >> remove the condition around line 95, the binaries work as expected.
> > Can you please run the installer script with "-R" so it doesn't perform
> > any relocation on binaries, and then:
> > 
> > readelf -p ".interp"
> > /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
> > 
> > It looks like the default dynamic loader path of the toolchain binaries
> > start with /lib* or /usr/lib* which is not quite right... It should be:
> > ${SDKPATH}/sysroots/${SDK_SYS}.
> 
> $ readelf -p ".interp"
> /usr/local/oecore-x86_64-non-reloc/sysroots/x86_64-angstromsdk-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
> 
> String dump of section '.interp':
>   [     0]  /lib64/ld-linux-x86-64.so.2
> 
> 
> So this looks wrong then, right? 
> 
> I also get the same for python and qmake:
> $ readelf -p ".interp" 
> /usr/local/oecore-x86_64-new/sysroots/x86_64-angstromsdk-linux/usr/bin/python2
> 
> String dump of section '.interp':
>   [     0]  /lib64/ld-linux-x86-64.so.2
> 
> $ readelf -p ".interp" 
> /usr/local/oecore-x86_64-new/sysroots/x86_64-angstromsdk-linux/usr/bin/qmake2
> 
> 
> String dump of section '.interp':
>   [     0]  /lib64/ld-linux-x86-64.so.2
> 
> How can I make sure all those binaries get linked against the SDK link
> loader?
> 
> --
> Stefan