[oe] [RFC] changing staging layout based on MULTIMACH_TARGET_SYS

Koen Kooi k.kooi at student.utwente.nl
Thu Jul 24 09:14:40 UTC 2008


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





More information about the Openembedded-devel mailing list