All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: [RFC] changing staging layout based on MULTIMACH_TARGET_SYS
Date: Thu, 24 Jul 2008 11:14:40 +0200	[thread overview]
Message-ID: <g69h61$qvv$1@ger.gmane.org> (raw)

Hi,

Lately I've been encountering various build problems that are caused by 
OE lumping all my ARM build together in 
staging/arm-angstrom-linux-gnueabi, which isn't quite right for the 
following reasons:

* it mixes hard- and softfloat when doing armv5te and armv6 builds, 
which introduces subtle compilation problems. The resulting binaries 
work fine together on the target, as one would expect with EABI, but 
mixing them in staging leads to troubles

* In an ideal world we would use a single compiler version for all 
subarchs, but for arm we use 4.2.4 for armv4, armv4t, armv5te and armv6, 
but 4.3.1 for armv7a. C++ apps don't like that

* You can end up statically linking an armv6 lib into an armv5te application

The same problems exist for powerpc (ppc405 vs ppc603e).

The change basically boils down to this on bitbake.conf:

-STAGING_BINDIR_CROSS  = "${STAGING_DIR_NATIVE}${layout_bindir}/${HOST_SYS}"
+STAGING_BINDIR_CROSS  = 
"${STAGING_DIR_NATIVE}${layout_bindir}/${MULTIMACH_HOST_SYS}"

-STAGING_DIR_HOST = "${STAGING_DIR}/${HOST_SYS}"
+STAGING_DIR_HOST = "${STAGING_DIR}/${MULTIMACH_HOST_SYS}"


-STAGING_DIR_TARGET = "${STAGING_DIR}/${TARGET_SYS}"
+STAGING_DIR_TARGET = "${STAGING_DIR}/${MULTIMACH_TARGET_SYS}"

Richard and I have been talking about this for a while now and the 
change landed in Poky last week.

This is however an ABI break for staging, so we need to do this as well:

--- conf/sanity.conf	2008/07/19 11:57:00	4892
+++ conf/sanity.conf	2008/07/19 11:59:42	4893
@@ -11,7 +11,7 @@
  # that breaks the format and have been previously discussed on the 
mailing list
  # with general agreement from the core team.
  #
-SANITY_ABI = "1"
+SANITY_ABI = "2"
  SANITY_ABIFILE = "${TMPDIR}/abi_version"

And as the diff points out, ABI breaks have to be discussed on the 
mailinglist.

I'd like to apply this right after the toolchain build order changes to 
minimize the number of full rebuilds people have to do.

Comments, objections?

regards,

Koen




             reply	other threads:[~2008-07-24  9:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-24  9:14 Koen Kooi [this message]
2008-08-05 13:10 ` [RFC] changing staging layout based on MULTIMACH_TARGET_SYS Florian Boor
  -- strict thread matches above, loose matches on Subject: below --
2008-07-28 12:43 Marcin Juszkiewicz

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='g69h61$qvv$1@ger.gmane.org' \
    --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 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.