From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: Re: Cleaning up SDK/Toolchain
Date: Thu, 18 Oct 2007 15:44:16 +0200 [thread overview]
Message-ID: <47176330.2000200@student.utwente.nl> (raw)
In-Reply-To: <1192708743.6158.25.camel@localhost.localdomain>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Richard Purdie schreef:
> On Thu, 2007-10-18 at 11:39 +0200, Koen Kooi wrote:
>> Apart from the libc flaw I pointed out in another mail, the naming of the toolchains is
>> broken as well:
>>
>> angstrom-2007.9-test-20071017-arm-linux-gnueabi-toolchain.tar.bz2
>> angstrom-2007.9-test-20071017-arm-linux-uclibcgnueabi-toolchain.tar.bz2
>> angstrom-2007.9-test-20071018-powerpc-linux-toolchain.tar.bz2
>> angstrom-2007.9-test-20071018-powerpc-linux-uclibc-toolchain.tar.bz2
>>
>> There's no way to see if the arm ones are armv4t, armv5te or armv6 and the powerpc ones
>> ppc405, ppc440 or ppc603e. For compiling 'hello world' that doesn't matter, but libc6.so
>> and libgcc_s.so will contain instruction not available on other cpus of that arch (e.g.
>> clz is not in armv4t), so your binary will probably not work on your device.
>>
>> My idea is to use PACKAGE_ARCH (e.g. armv5te or ppc603e) instead of TARGET_ARCH.
>>
>> Comments/hints/ideas?
>
> We actually have a bigger problem. Staging uses an arm directory, not an
> armv5te one so the armv5te binaries mix up with the armv4 ones etc.
>
> This isn't a problem with images built from packages where everything
> dynamically links since the right packages are used. The moment someone
> tries to statically link an armv4 binary with armv5te in staging, game
> over though.
>
> So both the meta-toolchain and staging need some thought (and are
> related since meta-toolchain has knowledge to rebuild bits of staging
> for use in its "shortcut an OE build by skipping the toolchain" mode.
>
> I agreed we probably need to add in some PACKAGE_ARCHs in places but its
> yet another thing that needs some careful thought and we'll probably
> break people's existing builds. I hope to look at/think about it soon if
> nobody beats me too it...
Can't we put it in at the same time as the staging /usr changes? We'll
be breaking stuff anyway...
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFHF2MwMkyGM64RGpERAkTbAJoDh5qic4QmFPw7N857kQm0rDabjgCgtcJ0
hqYD4JywIUYGwPtw8dgJnTM=
=Hlfq
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2007-10-18 13:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-17 13:25 Cleaning up SDK/Toolchain Michael 'Mickey' Lauer
2007-10-18 9:39 ` Koen Kooi
2007-10-18 11:59 ` Richard Purdie
2007-10-18 13:44 ` Koen Kooi [this message]
2007-10-18 17:30 ` Koen Kooi
2007-10-22 11:39 ` Koen Kooi
2007-10-22 14:36 ` Richard Purdie
2007-10-22 15:34 ` Koen Kooi
2007-10-22 16:43 ` Graeme Gregory
2007-10-22 18:24 ` Richard Purdie
2007-10-22 20:46 ` Leon Woestenberg
2007-10-22 21:02 ` Graeme Gregory
2007-10-23 2:33 ` mwester
2007-10-24 20:34 ` Koen Kooi
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=47176330.2000200@student.utwente.nl \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@openembedded.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox