SDK relocation issues

SDK relocation issues

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

Re: SDK relocation issues

[Laurentiu Palcu]

Hi Tasslehoff,

On Tue, Jun 11, 2013 at 11:35:26AM +0200, Tasslehoff Kjappfot wrote:
> 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)

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;

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

> 
> Regards,
> Tasslehoff
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: SDK relocation issues

[Tasslehoff Kjappfot]

Hi Laurentiu.

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

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

Re: SDK relocation issues

[Tasslehoff Kjappfot]

On 06/11/2013 02:43 PM, Laurentiu Palcu wrote:
> Hi Tasslehoff,
>
> On Tue, Jun 11, 2013 at 11:35:26AM +0200, Tasslehoff Kjappfot wrote:
>> 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)
>
> 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;
>
>>
>> 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

Re: SDK relocation issues

[Laurentiu Palcu]

On Tue, Jun 11, 2013 at 03:09:49PM +0200, Tasslehoff Kjappfot wrote:
> 
> 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.

> Maybe my "I can copy it wherever
> I want" interpretation of relocatable is the problem :)
Indeed, that's causing the issue. :)

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

> 
> Regards,
> Tasslehoff
> 
> 
> 
> 

Re: SDK relocation issues

[Tasslehoff Kjappfot]

On 06/11/2013 03:24 PM, Laurentiu Palcu wrote:> On Tue, Jun 11, 2013 at 
03:09:49PM +0200, Tasslehoff Kjappfot wrote:
 >>
 >> 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.
 >
 >> Maybe my "I can copy it wherever
 >> I want" interpretation of relocatable is the problem :)
 > Indeed, that's causing the issue. :)
 >
 >>
 >> 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