SDK relocation issues

DISCUSSION Tasslehoff Kjappfot 2 participants 6 messages Jun 11, 2013 – Jun 12, 2013

Share & tools

Tasslehoff Kjappfot

author

2013-06-11 09:35 UTC #0 lore raw

I compiled an SDK and extracted/installed it to my source tree instead of /usr/local/. I have made /usr/local/oecore-i686 a symlink to the actual location. With the latest Dylan this broke.

Denzil:
❯❯❯ ldd arm-angstrom-linux-gnueabi-gcc

    linux-gate.so.1 =>  (0xf771d000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7544000)

/usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xf771e000)

Dylan:
Original location:
❯❯❯ ldd arm-angstrom-linux-gnueabi-gcc

    linux-gate.so.1 =>  (0xf77c4000)
    libc.so.6 =>

/home/tasslehoff/src/pdrepos01/toolchains/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/armv7a-vfp-neon-angstrom-linux-gnueabi/./../../../lib/libc.so.6 (0xf7610000)

/home/tasslehoff/src/oe/toolchains/oecore-i686/sysroots/i686-angstromsdk-linux/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xf77c5000)

If I try to run the toolchain from Dylan on a system where /home/tasslehoff/src/oe/toolchains/oecore-i686/sysroots/i686-angstromsdk-linux/lib/ld-linux.so.2 does not exist, it fails.

Regards,
Tasslehoff

Laurentiu Palcu

2013-06-11 12:43 UTC #1 lore raw

Hi Tasslehoff,

Quoted 13 lines · Tasslehoff Kjappfot

I compiled an SDK and extracted/installed it to my source tree instead of /usr/local/. I have made /usr/local/oecore-i686 a symlink to the actual location. With the latest Dylan this broke.
Denzil:
❯❯❯ ldd arm-angstrom-linux-gnueabi-gcc
    linux-gate.so.1 =>  (0xf771d000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7544000) /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/lib/ld-linux.so.2
=> /lib/ld-linux.so.2 (0xf771e000)
Dylan:
Original location:
❯❯❯ ldd arm-angstrom-linux-gnueabi-gcc

Quoted 6 lines

    linux-gate.so.1 =>  (0xf77c4000)
    libc.so.6 => /home/tasslehoff/src/pdrepos01/toolchains/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/armv7a-vfp-neon-angstrom-linux-gnueabi/./../../../lib/libc.so.6
(0xf7610000)
/home/tasslehoff/src/oe/toolchains/oecore-i686/sysroots/i686-angstromsdk-linux/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xf77c5000)

A few things:
* Be careful when using ldd with SDK binaries. ldd it's just a wrapper script around host's dynamic loader and it might give you wrong paths (usually to the host's libraries). Luckily, in this case, the binary is relocatable and has the RPATH linked in, hence the libc.so.6 location is correct. However, the dynamic loader points to the host's. The correct way to print the dependencies for SDK bianaries is this:

   $ readelf -p .interp arm-poky-linux-gnueabi-gcc

String dump of section '.interp':

     [     0]  /home/test/sdk_tests/sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2

   $ /home/test/sdk_tests/sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 --list ./arm-poky-linux-gnueabi-gcc
        linux-vdso.so.1 (0x00007fff1a3f4000)
        libc.so.6 => /home/test/sdk_tests/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/./../../../lib/libc.so.6 (0x00007fc102465000)
        /home/test/sdk_tests/sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 (0x00007fc102868000)

* denzil did not support relocation and you could only install the sdk in /usr/local;
* AFAIK, the dynamic loader is always shipped with the SDK;

Quoted 3 lines

If I try to run the toolchain from Dylan on a system where /home/tasslehoff/src/oe/toolchains/oecore-i686/sysroots/i686-angstromsdk-linux/lib/ld-linux.so.2 does not exist, it fails.

Again, the DL should be available in your toolchain sysroot. I'm not aware of a case when the dynamic loader is not shipped with the toolchain. Did this happen in your case?

Thanks,
Laurentiu

Quoted 7 lines

Regards,
Tasslehoff
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Tasslehoff Kjappfot

author

2013-06-11 12:59 UTC #2 lore raw

Hi Laurentiu.

I just saw your mail, but won't have time to investigate until tomorrow. Just wanted to add one comment.

Quoted 2 lines

* denzil did not support relocation and you could only install the sdk in /usr/local;

In denzil I extracted the SDK to /home/tasslehoff/src/oe/toolchains/oecore-i686, and created a symlink there from /usr/local/oecore-i686. That worked well, and other devs just created the similar symlinks to where they had checked out their source tree. That is what I'm trying to do now as well.

Will read your mail again and investigate more tomorrow,

Regards,
Tasslehoff

Tasslehoff Kjappfot

author

2013-06-11 13:09 UTC #3 lore raw

In reply to Laurentiu Palcu

Quoted 45 lines · Laurentiu Palcu

Hi Tasslehoff,
Quoted 13 lines · Tasslehoff Kjappfot
I compiled an SDK and extracted/installed it to my source tree instead of /usr/local/. I have made /usr/local/oecore-i686 a symlink to the actual location. With the latest Dylan this broke.
Denzil:
❯❯❯ ldd arm-angstrom-linux-gnueabi-gcc
     linux-gate.so.1 =>  (0xf771d000)
     libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7544000) /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/lib/ld-linux.so.2
=> /lib/ld-linux.so.2 (0xf771e000)
Dylan:
Original location:
❯❯❯ ldd arm-angstrom-linux-gnueabi-gcc
Quoted 6 lines
     linux-gate.so.1 =>  (0xf77c4000)
     libc.so.6 => /home/tasslehoff/src/pdrepos01/toolchains/oecore-i686/sysroots/i686-angstromsdk-linux/usr/bin/armv7a-vfp-neon-angstrom-linux-gnueabi/./../../../lib/libc.so.6
(0xf7610000)
/home/tasslehoff/src/oe/toolchains/oecore-i686/sysroots/i686-angstromsdk-linux/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xf77c5000)
A few things:
* Be careful when using ldd with SDK binaries. ldd it's just a wrapper script around host's dynamic loader and it might give you wrong paths (usually to the host's libraries). Luckily, in this case, the binary is relocatable and has the RPATH linked in, hence the libc.so.6 location is correct. However, the dynamic loader points to the host's. The correct way to print the dependencies for SDK bianaries is this:
$ readelf -p .interp arm-poky-linux-gnueabi-gcc
String dump of section '.interp':
[ 0] /home/test/sdk_tests/sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2
$ /home/test/sdk_tests/sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 --list ./arm-poky-linux-gnueabi-gcc
linux-vdso.so.1 (0x00007fff1a3f4000)
libc.so.6 => /home/test/sdk_tests/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/./../../../lib/libc.so.6 (0x00007fc102465000) /home/test/sdk_tests/sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 (0x00007fc102868000)
* denzil did not support relocation and you could only install the sdk in /usr/local;
* AFAIK, the dynamic loader is always shipped with the SDK;
Quoted 1 line

Quoted 7 lines

Quoted 2 lines
If I try to run the toolchain from Dylan on a system where /home/tasslehoff/src/oe/toolchains/oecore-i686/sysroots/i686-angstromsdk-linux/lib/ld-linux.so.2 does not exist, it fails.
Again, the DL should be available in your toolchain sysroot. I'm not aware of a case when the dynamic loader is not shipped with the toolchain. Did this happen in your case?

I have time for one more :)

What does it mean that the SDK is relocatable? That I can choose when I run the .sh where I want to install it? Is it then "bound" to that directory, so that every dev that wants to use the SDK have to run the installer on their machine? Maybe my "I can copy it wherever I want" interpretation of relocatable is the problem :)

The DL is shipped with the toolchain, but is looked for in the path I installed to when I run the .sh. If I move the entire folder, I get the problems.

Regards,
Tasslehoff

Laurentiu Palcu

2013-06-11 13:24 UTC #4 lore raw

Quoted 7 lines · Tasslehoff Kjappfot

I have time for one more :)
What does it mean that the SDK is relocatable? That I can choose when I run the .sh where I want to install it? Is it then "bound" to that directory, so that every dev that wants to use the SDK have to run the installer on their machine?

That's correct. Each developer can install the SDK wherever he/she wants to.

Quoted 2 lines

Maybe my "I can copy it wherever
I want" interpretation of relocatable is the problem :)

Indeed, that's causing the issue. :)

Quoted 4 lines

The DL is shipped with the toolchain, but is looked for in the path I installed to when I run the .sh. If I move the entire folder, I get the problems.

When the relocation process takes place, it changes the path to the dynamic loader in all binaries. Moving the SDK to another location would imply re-running the installer again and choose the new location as destination.

Thanks,
Laurentiu

Quoted 7 lines

Regards,
Tasslehoff

Tasslehoff Kjappfot

author

2013-06-12 06:19 UTC #5 lore raw

Quoted 16 lines · Tasslehoff Kjappfot

Quoted 7 lines
I have time for one more :)
What does it mean that the SDK is relocatable? That I can choose when I run the .sh where I want to install it? Is it then "bound" to that directory, so that every dev that wants to use the SDK have to run the installer on their machine?
That's correct. Each developer can install the SDK wherever he/she wants to.
Quoted 2 lines
Maybe my "I can copy it wherever
I want" interpretation of relocatable is the problem :)
Indeed, that's causing the issue. :)
Quoted 1 line

Quoted 8 lines

Quoted 3 lines
The DL is shipped with the toolchain, but is looked for in the path I installed to when I run the .sh. If I move the entire folder, I get the problems.
When the relocation process takes place, it changes the path to the dynamic loader in all binaries. Moving the SDK to another location would imply re-running the installer again and choose the new location as destination.

Thanks for explaining this. The reason we did it the way I described is that when checking out older source we would automatically get the toolchain we used at the time. Not sure how to solve this now, but I guess keeping multiple toolchains installed will work. Any other suggestions?

Regards,
Tasslehoff