All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Björn Krombholz" <pirobk@gmail.com>
To: Mark Hatle <mark.hatle@windriver.com>, Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: meta-toolchain doesn't compile working binaries
Date: Wed, 07 May 2014 14:54:41 +0200	[thread overview]
Message-ID: <536A2D11.8000009@gmail.com> (raw)
In-Reply-To: <536957A8.90300@windriver.com>

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


  parent reply	other threads:[~2014-05-07 12:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=536A2D11.8000009@gmail.com \
    --to=pirobk@gmail.com \
    --cc=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.