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" <[email protected]
<mailto:[email protected]>> 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.
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
