* meta-toolchain doesn't compile working binaries
@ 2014-05-06 8:14 Björn Krombholz
2014-05-06 17:01 ` Khem Raj
2014-05-06 20:55 ` Denys Dmytriyenko
0 siblings, 2 replies; 17+ messages in thread
From: Björn Krombholz @ 2014-05-06 8:14 UTC (permalink / raw)
To: openembedded-core
Hi,
I'm having trouble building a working toolchain (meta-toolchain) on yocto-1.4 release.
Buildsystem is x86_64, on current Debian Sid.
The problem seems to be with ld-linux[...].so, SDKMACHINE doesn't seem to matter (x86_64 and i686 produce broken binaries).
The effect is, that (almost) every binary in the toolchain segfaults when being run.
Example m4:
(in /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux)
Host ld:
$ usr/bin/m4 --help
Segmentation fault
Explicitly using the toolchain ld:
$ lib/ld-linux-x86-64.so.2 usr/bin/m4 --help
Usage: usr/bin/m4 [OPTION]... [FILE]...
[...]
Comparing the build with a toolchain created on Jul 30th 2013 (which works fine) I see one major difference:
Old (working) toolchain:
$ ldd m4
linux-vdso.so.1 (0x00007fffdae00000)
libc.so.6 => /usr/local/oecore-x86_64.old_201307/sysroots/x86_64-angstromsdk-linux/usr/bin/./../../lib/libc.so.6 (0x00007f6a71ed0000)
/usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f6a72280000)
New (broken) toolchain:
$ ldd m4
linux-vdso.so.1 (0x00007fff36e00000)
libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/./../../lib/libc.so.6 (0x00007f00e7860000)
/lib64/ld-linux-x86-64.so.2 (0x00007f00e7c10000)
The internal toolchain (from tmp/build/) is working fine, though the ldd output looks similar to the broken built one:
[...]build/tmp-angstrom_v2013_06-eglibc/sysroots/x86_64-linux/usr/bin$ ldd m4
linux-vdso.so.1 (0x00007fff9fdc8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f481cda8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f481d188000)
ATM, on Debian Sid /lib64/ld-linux-x86-64.so.2 is just a link /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.18.so
I'd appreciate if someone could give me a hint on this matter, or a point me in a direction, where the problem might be.
As mentioned I already tried changing the SDKMACHINE and a completely clean build folder with no effect.
Thanks
Björn
--
Björn Krombholz
pironex GmbH -- http://www.pironex.de
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: meta-toolchain doesn't compile working binaries 2014-05-06 8:14 meta-toolchain doesn't compile working binaries Björn Krombholz @ 2014-05-06 17:01 ` Khem Raj 2014-05-06 20:55 ` Denys Dmytriyenko 1 sibling, 0 replies; 17+ messages in thread From: Khem Raj @ 2014-05-06 17:01 UTC (permalink / raw) To: Björn Krombholz; +Cc: Patches and discussions about the oe-core layer On Tue, May 6, 2014 at 1:14 AM, Björn Krombholz <pirobk@gmail.com> wrote: > Comparing the build with a toolchain created on Jul 30th 2013 (which works fine) I see one major difference: what is the delta between the working and non working OE-Core repo ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 8:14 meta-toolchain doesn't compile working binaries Björn Krombholz 2014-05-06 17:01 ` Khem Raj @ 2014-05-06 20:55 ` Denys Dmytriyenko 2014-05-06 20:56 ` Khem Raj 1 sibling, 1 reply; 17+ messages in thread From: Denys Dmytriyenko @ 2014-05-06 20:55 UTC (permalink / raw) To: Björn Krombholz; +Cc: openembedded-core On Tue, May 06, 2014 at 10:14:45AM +0200, Björn Krombholz wrote: > Hi, > > I'm having trouble building a working toolchain (meta-toolchain) on > yocto-1.4 release. > > Buildsystem is x86_64, on current Debian Sid. > > The problem seems to be with ld-linux[...].so, SDKMACHINE doesn't seem to > matter (x86_64 and i686 produce broken binaries). > > The effect is, that (almost) every binary in the toolchain segfaults when > being run. > > > Example m4: > (in /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux) > > Host ld: > $ usr/bin/m4 --help > Segmentation fault > > Explicitly using the toolchain ld: > $ lib/ld-linux-x86-64.so.2 usr/bin/m4 --help > Usage: usr/bin/m4 [OPTION]... [FILE]... > [...] > > > Comparing the build with a toolchain created on Jul 30th 2013 (which works > fine) I see one major difference: > > Old (working) toolchain: > $ ldd m4 > linux-vdso.so.1 (0x00007fffdae00000) > libc.so.6 => /usr/local/oecore-x86_64.old_201307/sysroots/x86_64-angstromsdk-linux/usr/bin/./../../lib/libc.so.6 (0x00007f6a71ed0000) > /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f6a72280000) > > > New (broken) toolchain: > $ ldd m4 > linux-vdso.so.1 (0x00007fff36e00000) > libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/./../../lib/libc.so.6 (0x00007f00e7860000) > /lib64/ld-linux-x86-64.so.2 (0x00007f00e7c10000) > > > The internal toolchain (from tmp/build/) is working fine, though the ldd output looks similar to the broken built one: > > [...]build/tmp-angstrom_v2013_06-eglibc/sysroots/x86_64-linux/usr/bin$ ldd m4 > linux-vdso.so.1 (0x00007fff9fdc8000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f481cda8000) > /lib64/ld-linux-x86-64.so.2 (0x00007f481d188000) > > ATM, on Debian Sid /lib64/ld-linux-x86-64.so.2 is just a link > /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.18.so > > I'd appreciate if someone could give me a hint on this matter, or a point me > in a direction, where the problem might be. As mentioned I already tried > changing the SDKMACHINE and a completely clean build folder with no effect. Do you know that OE toolchain is not relocatable? The above symptoms are very similar to when you try to execute toolchain binaries from a different location that the toolchain was built for or installed to. There is a script called relocate_sdk.py that adjusts binaries and libraries to work in the required location - it's called during install of the SDK. See pages 24-27 of my last year ELC presentation about more details on how OE SDK works: http://elinux.org/images/c/c8/ExternalToolchainsInYocto.pdf -- Denys ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 20:55 ` Denys Dmytriyenko @ 2014-05-06 20:56 ` Khem Raj 2014-05-06 20:59 ` Denys Dmytriyenko 2014-05-06 21:25 ` Mark Hatle 0 siblings, 2 replies; 17+ messages in thread From: Khem Raj @ 2014-05-06 20:56 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: Patches and discussions about the oe-core layer On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org> wrote: > Do you know that OE toolchain is not relocatable? is that true ? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 20:56 ` Khem Raj @ 2014-05-06 20:59 ` Denys Dmytriyenko 2014-05-06 21:25 ` Mark Hatle 1 sibling, 0 replies; 17+ messages in thread From: Denys Dmytriyenko @ 2014-05-06 20:59 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer On Tue, May 06, 2014 at 01:56:57PM -0700, Khem Raj wrote: > On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org> wrote: > > Do you know that OE toolchain is not relocatable? > > is that true ? Is not auto-relocatable - is it better? -- Denys ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 20:56 ` Khem Raj 2014-05-06 20:59 ` Denys Dmytriyenko @ 2014-05-06 21:25 ` Mark Hatle 2014-05-06 21:40 ` Khem Raj 2014-05-06 21:44 ` Denys Dmytriyenko 1 sibling, 2 replies; 17+ messages in thread From: Mark Hatle @ 2014-05-06 21:25 UTC (permalink / raw) To: openembedded-core On 5/6/14, 3:56 PM, Khem Raj wrote: > On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org> wrote: >> Do you know that OE toolchain is not relocatable? > > is that true ? > It's the load path of the executables, they use the libc-nativesdk, so they need a hard path to the correct ld.so to get started. --Mark ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 21:25 ` Mark Hatle @ 2014-05-06 21:40 ` Khem Raj 2014-05-06 21:44 ` Mark Hatle 2014-05-06 21:44 ` Denys Dmytriyenko 1 sibling, 1 reply; 17+ messages in thread From: Khem Raj @ 2014-05-06 21:40 UTC (permalink / raw) To: Mark Hatle; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 696 bytes --] On May 6, 2014 2:25 PM, "Mark Hatle" <mark.hatle@windriver.com> wrote: > > On 5/6/14, 3:56 PM, Khem Raj wrote: >> >> On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org> wrote: >>> >>> Do you know that OE toolchain is not relocatable? >> >> >> is that true ? >> > > It's the load path of the executables, they use the libc-nativesdk, so they need a hard path to the correct ld.so to get started. isnt this fixed by the installer when it is run > > --Mark > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core [-- Attachment #2: Type: text/html, Size: 1159 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 21:40 ` Khem Raj @ 2014-05-06 21:44 ` Mark Hatle 2014-05-06 21:49 ` Denys Dmytriyenko 2014-05-07 12:54 ` Björn Krombholz 0 siblings, 2 replies; 17+ messages in thread From: Mark Hatle @ 2014-05-06 21:44 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer 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: > > > > On 5/6/14, 3:56 PM, Khem Raj wrote: > >> > >> On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org > <mailto:denis@denix.org>> wrote: > >>> > >>> Do you know that OE toolchain is not relocatable? > >> > >> > >> is that true ? > >> > > > > It's the load path of the executables, they use the libc-nativesdk, 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.) --Mark > > > > --Mark > > > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > <mailto:Openembedded-core@lists.openembedded.org> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 21:44 ` Mark Hatle @ 2014-05-06 21:49 ` Denys Dmytriyenko 2014-05-07 12:54 ` Björn Krombholz 1 sibling, 0 replies; 17+ messages in thread From: Denys Dmytriyenko @ 2014-05-06 21:49 UTC (permalink / raw) To: Mark Hatle; +Cc: Patches and discussions about the oe-core layer On Tue, May 06, 2014 at 04:44:08PM -0500, 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: > > > > > > On 5/6/14, 3:56 PM, Khem Raj wrote: > > >> > > >> On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org > ><mailto:denis@denix.org>> wrote: > > >>> > > >>> Do you know that OE toolchain is not relocatable? > > >> > > >> > > >> is that true ? > > >> > > > > > > It's the load path of the executables, they use the libc-nativesdk, 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. Exactly what I said earlier about using relocate_sdk.py in the installer, which Khem conveniently ignored and removed when replying... :) Just kidding. > (If the installer -was- used, then it's definitely a bug.) There's no bug as far as I know, as SDK/toolchain is a major part of our product and we test it actively with every release. -- Denys ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 21:44 ` Mark Hatle 2014-05-06 21:49 ` Denys Dmytriyenko @ 2014-05-07 12:54 ` Björn Krombholz 2014-05-07 14:37 ` Mark Hatle 2014-05-07 14:58 ` Björn Krombholz 1 sibling, 2 replies; 17+ messages in thread From: Björn Krombholz @ 2014-05-07 12:54 UTC (permalink / raw) To: Mark Hatle, Khem Raj; +Cc: Patches and discussions about the oe-core layer 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) 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. -- Björn Krombholz pironex GmbH -- http://www.pironex.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-07 12:54 ` Björn Krombholz @ 2014-05-07 14:37 ` Mark Hatle 2014-05-07 14:58 ` Björn Krombholz 1 sibling, 0 replies; 17+ messages in thread From: Mark Hatle @ 2014-05-07 14:37 UTC (permalink / raw) To: Björn Krombholz, Khem Raj Cc: Patches and discussions about the oe-core layer 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. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-07 12:54 ` Björn Krombholz 2014-05-07 14:37 ` Mark Hatle @ 2014-05-07 14:58 ` Björn Krombholz 2014-05-07 17:13 ` Björn Krombholz 1 sibling, 1 reply; 17+ messages in thread From: Björn Krombholz @ 2014-05-07 14:58 UTC (permalink / raw) To: Mark Hatle, Khem Raj; +Cc: Patches and discussions about the oe-core layer On 05/07/2014 02:54 PM, Björn Krombholz wrote: > 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. [...] > 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. Quick followup. yocto-1.5 / Angstrom-v2013.12 _does_ work as expected. -- Björn Krombholz pironex GmbH -- http://www.pironex.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-07 14:58 ` Björn Krombholz @ 2014-05-07 17:13 ` Björn Krombholz 0 siblings, 0 replies; 17+ messages in thread From: Björn Krombholz @ 2014-05-07 17:13 UTC (permalink / raw) To: Mark Hatle, Khem Raj; +Cc: Patches and discussions about the oe-core layer On 05/07/2014 04:58 PM, Björn Krombholz wrote: > On 05/07/2014 02:54 PM, Björn Krombholz wrote: >> 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. > [...] >> 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. > > Quick followup. > > yocto-1.5 / Angstrom-v2013.12 _does_ work as expected. > ...meaning, binaries do run without segfaulting, though as Mark suggested, there shouldn't be any reference to the hosts /lib64/... The ldd output for an installed nativesdk-m4 from yocto-1.5 looks like: # ldd m4 linux-vdso.so.1 (0x00007fff92700000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/./../../lib/libc.so.6 (0x00007f8aa86e8000) /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f8aa8a98000) # ls -l /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld* -rwxr-xr-x 1 root root 149304 May 7 16:00 /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-2.18-2013.10.so lrwxrwxrwx 1 root root 18 May 7 16:01 /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-linux-x86-64.so.2 -> ld-2.18-2013.10.so :-/ -- Björn Krombholz pironex GmbH -- http://www.pironex.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 21:25 ` Mark Hatle 2014-05-06 21:40 ` Khem Raj @ 2014-05-06 21:44 ` Denys Dmytriyenko 2014-05-06 21:49 ` Mark Hatle 1 sibling, 1 reply; 17+ messages in thread From: Denys Dmytriyenko @ 2014-05-06 21:44 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core On Tue, May 06, 2014 at 04:25:15PM -0500, Mark Hatle wrote: > On 5/6/14, 3:56 PM, Khem Raj wrote: > >On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org> wrote: > >>Do you know that OE toolchain is not relocatable? > > > >is that true ? > > > > It's the load path of the executables, they use the libc-nativesdk, > so they need a hard path to the correct ld.so to get started. More specifically, it's PT_INTERP section of the ELF header in every binary that hardcodes the full path to our own dynamic linker/loader (i.e. mentioned libc-nativesdk). I wish it would support the use of $ORIGIN similar to RPATH and RUNPATH for libraries, but I bet there are all kinds of corner cases with that... :) -- Denys ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 21:44 ` Denys Dmytriyenko @ 2014-05-06 21:49 ` Mark Hatle 2014-05-06 21:59 ` Denys Dmytriyenko 0 siblings, 1 reply; 17+ messages in thread From: Mark Hatle @ 2014-05-06 21:49 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: openembedded-core On 5/6/14, 4:44 PM, Denys Dmytriyenko wrote: > On Tue, May 06, 2014 at 04:25:15PM -0500, Mark Hatle wrote: >> On 5/6/14, 3:56 PM, Khem Raj wrote: >>> On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org> wrote: >>>> Do you know that OE toolchain is not relocatable? >>> >>> is that true ? >>> >> >> It's the load path of the executables, they use the libc-nativesdk, >> so they need a hard path to the correct ld.so to get started. > > More specifically, it's PT_INTERP section of the ELF header in every binary > that hardcodes the full path to our own dynamic linker/loader (i.e. mentioned > libc-nativesdk). I wish it would support the use of $ORIGIN similar to RPATH > and RUNPATH for libraries, but I bet there are all kinds of corner cases with > that... :) > $ORIGIN, RPATH and RUNPATH are all implemented by the ld.so, there is no way to dynamically assign the interpreter (ld.so). --Mark ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 21:49 ` Mark Hatle @ 2014-05-06 21:59 ` Denys Dmytriyenko 2014-05-07 15:27 ` Richard Purdie 0 siblings, 1 reply; 17+ messages in thread From: Denys Dmytriyenko @ 2014-05-06 21:59 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core On Tue, May 06, 2014 at 04:49:09PM -0500, Mark Hatle wrote: > On 5/6/14, 4:44 PM, Denys Dmytriyenko wrote: > >On Tue, May 06, 2014 at 04:25:15PM -0500, Mark Hatle wrote: > >>On 5/6/14, 3:56 PM, Khem Raj wrote: > >>>On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org> wrote: > >>>>Do you know that OE toolchain is not relocatable? > >>> > >>>is that true ? > >>> > >> > >>It's the load path of the executables, they use the libc-nativesdk, > >>so they need a hard path to the correct ld.so to get started. > > > >More specifically, it's PT_INTERP section of the ELF header in every binary > >that hardcodes the full path to our own dynamic linker/loader (i.e. mentioned > >libc-nativesdk). I wish it would support the use of $ORIGIN similar to RPATH > >and RUNPATH for libraries, but I bet there are all kinds of corner cases with > >that... :) > > > > $ORIGIN, RPATH and RUNPATH are all implemented by the ld.so, there > is no way to dynamically assign the interpreter (ld.so). Yes, the above wish was highly abstract and hypothetical and would probably require kernel to support $ORIGIN used in the ELF header... But I'm not suggesting it, just speculating! :) -- Denys ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: meta-toolchain doesn't compile working binaries 2014-05-06 21:59 ` Denys Dmytriyenko @ 2014-05-07 15:27 ` Richard Purdie 0 siblings, 0 replies; 17+ messages in thread From: Richard Purdie @ 2014-05-07 15:27 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: openembedded-core On Tue, 2014-05-06 at 17:59 -0400, Denys Dmytriyenko wrote: > On Tue, May 06, 2014 at 04:49:09PM -0500, Mark Hatle wrote: > > On 5/6/14, 4:44 PM, Denys Dmytriyenko wrote: > > >On Tue, May 06, 2014 at 04:25:15PM -0500, Mark Hatle wrote: > > >>On 5/6/14, 3:56 PM, Khem Raj wrote: > > >>>On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org> wrote: > > >>>>Do you know that OE toolchain is not relocatable? > > >>> > > >>>is that true ? > > >>> > > >> > > >>It's the load path of the executables, they use the libc-nativesdk, > > >>so they need a hard path to the correct ld.so to get started. > > > > > >More specifically, it's PT_INTERP section of the ELF header in every binary > > >that hardcodes the full path to our own dynamic linker/loader (i.e. mentioned > > >libc-nativesdk). I wish it would support the use of $ORIGIN similar to RPATH > > >and RUNPATH for libraries, but I bet there are all kinds of corner cases with > > >that... :) > > > > > > > $ORIGIN, RPATH and RUNPATH are all implemented by the ld.so, there > > is no way to dynamically assign the interpreter (ld.so). > > Yes, the above wish was highly abstract and hypothetical and would probably > require kernel to support $ORIGIN used in the ELF header... But I'm not > suggesting it, just speculating! :) Right, that would need support in the kernel and would mean that the SDK was restricted to specific kernel versions. Having said that, I have wondered if we could see if we could get it in and then someday remove this restriction. Cheers, Richard ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-05-07 17:13 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-05-06 8:14 meta-toolchain doesn't compile working binaries Björn Krombholz 2014-05-06 17:01 ` Khem Raj 2014-05-06 20:55 ` Denys Dmytriyenko 2014-05-06 20:56 ` Khem Raj 2014-05-06 20:59 ` Denys Dmytriyenko 2014-05-06 21:25 ` Mark Hatle 2014-05-06 21:40 ` Khem Raj 2014-05-06 21:44 ` Mark Hatle 2014-05-06 21:49 ` Denys Dmytriyenko 2014-05-07 12:54 ` Björn Krombholz 2014-05-07 14:37 ` Mark Hatle 2014-05-07 14:58 ` Björn Krombholz 2014-05-07 17:13 ` Björn Krombholz 2014-05-06 21:44 ` Denys Dmytriyenko 2014-05-06 21:49 ` Mark Hatle 2014-05-06 21:59 ` Denys Dmytriyenko 2014-05-07 15:27 ` Richard Purdie
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.