[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