Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: Re: Cleaning up SDK/Toolchain
Date: Mon, 22 Oct 2007 17:34:53 +0200	[thread overview]
Message-ID: <471CC31D.2010401@student.utwente.nl> (raw)
In-Reply-To: <1193063767.6088.54.camel@localhost.localdomain>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Mon, 2007-10-22 at 13:39 +0200, Koen Kooi wrote:
>> Richard Purdie schreef:
>>> 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...
>> Hopefully[1] it's as simple as:
>>
>> ============================================================
>> - --- conf/bitbake.conf   f410a6b3af115612f2bd104814d1035583d3518a
>> +++ conf/bitbake.conf   3391cfd9df2450e4090fa01879fab5f5e7b100a8
>> @@ -45,6 +45,7 @@ HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-$
>>  HOST_OS = "${TARGET_OS}"
>>  HOST_VENDOR = "${TARGET_VENDOR}"
>>  HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"
>> +STAGING_SYS = "${PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}"
>>  HOST_PREFIX = "${TARGET_PREFIX}"
>>  HOST_CC_ARCH = "${TARGET_CC_ARCH}"
>>
>> @@ -167,16 +168,16 @@ STAGING_DIR = "${TMPDIR}/staging"
>>  B = "${S}"
>>
>>  STAGING_DIR = "${TMPDIR}/staging"
>> - -STAGING_BINDIR = "${STAGING_DIR}/${HOST_SYS}/bin"
>> +STAGING_BINDIR = "${STAGING_DIR}/${STAGING_SYS}/bin"
>>  STAGING_BINDIR_CROSS = "${STAGING_DIR}/${BUILD_SYS}/bin/${HOST_SYS}"
>>  STAGING_BINDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/bin"
>> - -STAGING_LIBDIR = "${STAGING_DIR}/${HOST_SYS}/lib"
>> +STAGING_LIBDIR = "${STAGING_DIR}/${STAGING_SYS}/lib"
>>  STAGING_LIBDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/lib"
>>  STAGING_ETCDIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}/etc"
>> - -STAGING_INCDIR = "${STAGING_DIR}/${HOST_SYS}/include"
>> - -STAGING_DATADIR = "${STAGING_DIR}/${HOST_SYS}/share"
>> - -STAGING_LOADER_DIR = "${STAGING_DIR}/${HOST_SYS}/loader"
>> - -STAGING_FIRMWARE_DIR = "${STAGING_DIR}/${HOST_SYS}/firmware"
>> +STAGING_INCDIR = "${STAGING_DIR}/${STAGING_SYS}/include"
>> +STAGING_DATADIR = "${STAGING_DIR}/${STAGING_SYS}/share"
>> +STAGING_LOADER_DIR = "${STAGING_DIR}/${STAGING_SYS}/loader"
>> +STAGING_FIRMWARE_DIR = "${STAGING_DIR}/${STAGING_SYS}/firmware"
>>  STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4"
> 
>> [1] I suspect this 'breaks' machine specific packages, but we'll see
> 
> I suspect you'll be right. This actually turns into a nightmare the more
> you think about it.
> 
> Consider we have libfoo which is compiled with iwmmxt optimisations for
> iwmmxt machines and without iwmmxt optimisations for other arm machines.
> appfoo statically links against this. 
> 
> I can think of a few ways we could handle this and other issues
> generically:
> 
> * We could have a staging lib directory per PACKAGE_ARCH and then join
> them all together with CFLAGS/LDFLAGS as you suggested on irc. I think
> it will get really really messy though.
> 
> * Each machine could have its own staging area. To do that you'd have to
> make the populate staging stamp machine specific. That is possible
> although bitbake might require some tweaks and it would have
> implications for rm_work.

In essence it would make multimachine unimachine :(

> * We implement packaged staging and only stage the dependencies needed
> for each package.

That would be a better approach. Graeme, do you still want to have a
shot at implementing a unionfs based approach?

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHHMMdMkyGM64RGpERAnMYAJ0dp0rCX5jJK0DXLT81afSFZdGB0ACeM5p3
Mqjknw8D+MjtWMU+tGV7dck=
=zDLu
-----END PGP SIGNATURE-----



  reply	other threads:[~2007-10-22 15:42 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
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 [this message]
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=471CC31D.2010401@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