Re: meta-toolchain doesn't compile working binaries

[Mark Hatle <mark.hatle@windriver.com>]

On 5/7/14, 7:54 AM, Björn Krombholz wrote:
> On 05/06/2014 11:44 PM, Mark Hatle wrote:
>> On 5/6/14, 4:40 PM, Khem Raj wrote:
>>>
>>> On May 6, 2014 2:25 PM, "Mark Hatle" <mark.hatle@windriver.com
>>> <mailto:mark.hatle@windriver.com>> wrote:
>>> so they
>>> need a hard path to the correct ld.so to get started.
>>>
>>> isnt this fixed by the installer when it is run
>>
>> Yes, it sounds like either he moved the files after the the installer
>> ran, or didn't use the installer at all and just tried to execute them
>> out of the build system.
>>
>> (If the installer -was- used, then it's definitely a bug.)
>
>
> The installer _was_ used, I didn't move any files and used the default
> location /usr/local/oecore-[...]
>
> Thanks for the hints.
>
> Additional note, in case it was missed: I am using v2013.06 (yocto 1.4 base, Angstrom variant)
>
>
> I guess the problem is, that the relocation_sdk.py excludes /lib/ and
> 32/64 bit variants.
>
> I just
> - re-run the installer with -S
> - edited the extracted relocation script commented the lines out:
>
>              #if fname.startswith("/lib/") or fname.startswith("/lib64/") or fname.startswith("/lib32/") or fname.startswith("/usr/lib32/") or fname.startswith("/usr/lib32/") or fname.startswith("/usr/lib64/"):
>              #    break
>
> - re-run the relocation
>
> Now I see the expected result, matching the "old" toolchain from summer 2013:
> # ldd /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/m4
>          linux-vdso.so.1 (0x00007fffe6800000)
>          libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/../../lib/libc.so.6 (0x00007f86e8110000)
>          /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f86e84c0000)

The bove may work, but it's incorrect.  It appears to be trying to run:
   /lib64/ld-linux-x86-64.so.2, -instead- of
 
/usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-linux-x86-64.so.2

The check is there specifically because some distribution creators add software 
that is expected to use the host system's ld.so (ld-linux-x86-64.so.2 in this 
case) loader.  So we detect that behavior by looking for system paths embedded 
into a particular binaries executable.

In this case, where m4 is provided as a nativesdk item, there should be no 
references at all to the system /lib64/ld-linux-x86-64.so.2.

I'm not familiar with the YP 1.4 + Angstrom variant to expand on this and 
determine where the error actually is.  But in general nativesdk elements 
referencing any type of system ld.so is incorrect.

--Mark

> Executing the binary works as well.
>
>
> Comparing the binaries from the current toolchain with those from the old one skipping the relocation step (extracted toolchain with -R) shows:
>
> Old and working:
> # ldd m4
>          linux-vdso.so.1 (0x00007fffb1800000)
>          libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/./../../lib/libc.so.6 (0x00007f50bd210000)
>          /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f50bd5c0000)
>
> New and broken:
> # ldd m4
>          linux-vdso.so.1 (0x00007fff6c000000)
>          libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/./../../lib/libc.so.6 (0x00007fefc1de8000)
>          /lib64/ld-linux-x86-64.so.2 (0x00007fefc2198000)
>
> /lib64/ obviously doesn't get replaced.
>
> I have no clue how to debug this any further. Not even sure if the problem is more likely related to eglibc packages or somewhere hidden in the general OE build scripts. :/
>
> I will build a v2013.12 version now and check if there is any difference.
>