From: Martin Jansa <martin.jansa@gmail.com>
To: Chris Larson <clarson@kergoth.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Does support for external toolchains working in current OE?
Date: Sat, 6 Apr 2013 14:43:57 +0200 [thread overview]
Message-ID: <20130406124357.GC3196@jama> (raw)
In-Reply-To: <CA+chaQdLwM_iLaCA=aq19q941CEKKAhbJb9L8Oe=TVd4sDU9wA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3679 bytes --]
On Sat, Apr 06, 2013 at 12:10:01AM +0200, Martin Jansa wrote:
> I've already tried that, systemd's configure does not respect that.
I've patch for systemd which "fixes" this:
diff --git a/meta/recipes-core/systemd/systemd_199.bb b/meta/recipes-core/systemd/systemd_199.bb
index e574548..2bb9566 100644
--- a/meta/recipes-core/systemd/systemd_199.bb
+++ b/meta/recipes-core/systemd/systemd_199.bb
@@ -76,6 +76,15 @@ EXTRA_OECONF_append_libc-uclibc = " --disable-myhostname "
do_configure_prepend() {
export CPP="${HOST_PREFIX}cpp ${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
+ # Allow to override them from shell variables with right prefix
+ # in some cases (external toolchain) HOST_PREFIX is not the same as HOST_SYS
+ sed -i "s#AC_PATH_TOOL(OBJCOPY,#AC_CHECK_TOOL(OBJCOPY,#g; \
+ s#AC_PATH_TOOL(STRINGS,#AC_CHECK_TOOL(STRINGS,#g; \
+ s#AC_PATH_TOOL(GPERF,#AC_CHECK_TOOL(GPERF,#g" ${S}/configure.ac
+ # OBJCOPY is already exported by default
+ export STRINGS="${HOST_PREFIX}strings"
+ export GPERF="${HOST_PREFIX}gperf"
+
sed -i -e 's:=/root:=${ROOT_HOME}:g' units/*.service*
}
But I'm still looking for some more global solution, what can go wrong when
external toolchain overwrites HOST_SYS to match overwritten TARGET_PREFIX?
e.g.
tcmode-external-sourcery.inc:TARGET_PREFIX = "${CSL_TARGET_SYS}-"
bitbake.conf:
HOST_ARCH = "${TARGET_ARCH}"
HOST_OS = "${TARGET_OS}"
HOST_VENDOR = "${TARGET_VENDOR}"
HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"
HOST_PREFIX = "${TARGET_PREFIX}"
TARGET_ARCH = "${TUNE_ARCH}"
TARGET_OS = "linux${LIBCEXTENSION}${ABIEXTENSION}"
TARGET_VENDOR = "-oe"
TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' + d.getVar('TARGET_OS', True), ''][d.getVar('TARGET_OS', True) == ('' or 'custom')]}"
TARGET_PREFIX = "${TARGET_SYS}-"
So when external-tc changes TARGET_PREFIX, it modifies HOST_PREFIX and
both are inconsistent with TARGET_SYS/HOST_SYS which is used by autoconf
for AC_PATH_TOOL.
> On Sat, Apr 6, 2013 at 12:08 AM, Chris Larson <clarson@kergoth.com> wrote:
>
> >
> > On Fri, Apr 5, 2013 at 2:20 PM, Martin Jansa <martin.jansa@gmail.com>wrote:
> >
> >> On Fri, Apr 05, 2013 at 11:20:44AM +0200, Marcin Juszkiewicz wrote:
> >> > For last few months I am working on fixing Linaro binary cross
> >> > toolchains and their support in OpenEmbedded. Got to point when they
> >> > work (both AArch64 and ARMv7a ones) for single packages but problem
> >> > starts when I want to create image...
> >>
> >> Today I got different king of issue with external toolchain.
> >>
> >> systemd is using AC_PATH_TOOL(OBJCOPY, objcopy)
> >> but host prefix in OE is not the same as in binary toolchain (different
> >> TARGET_VENDOR)
> >> so it looks for configure:14545: checking for
> >> arm-foo-linux-gnueabi-objcopy
> >> while binary toolchain has only
> >> arm-bar-linux-gnueabi-objcopy
> >>
> >> and because arm-foo-linux-gnueabi-objcopy wasn't found it continues:
> >> configure:14588: checking for objcopy
> >> configure:14606: found /usr/bin/objcopy
> >> and bam a lot later when it tries objcopy from host on some arm lib
> >>
> >> Interesting that systemd is first recipe in our image where I've noticed
> >> issues like this
> >>
> >> Any idea how to easily resolve this without checking every configure.ac
> >> how it's looking for e.g. objcopy?
> >
> >
> > export OBJCOPY in the environment to the one based on TARGET_PREFIX rather
> > than TARGET_SYS, and it'll use that.
> > --
> > Christopher Larson
> >
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
prev parent reply other threads:[~2013-04-06 13:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-05 9:20 Does support for external toolchains working in current OE? Marcin Juszkiewicz
2013-04-05 9:26 ` Marcin Juszkiewicz
2013-04-05 9:54 ` Richard Purdie
2013-04-05 9:56 ` Marcin Juszkiewicz
2013-04-05 10:11 ` Richard Purdie
2013-04-05 11:48 ` Marcin Juszkiewicz
2013-04-05 12:21 ` Marcin Juszkiewicz
2013-04-05 12:26 ` Marcin Juszkiewicz
2013-04-05 12:31 ` Richard Purdie
2013-04-05 21:20 ` Martin Jansa
2013-04-05 22:08 ` Chris Larson
2013-04-05 22:10 ` Martin Jansa
2013-04-06 12:43 ` Martin Jansa [this message]
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=20130406124357.GC3196@jama \
--to=martin.jansa@gmail.com \
--cc=clarson@kergoth.com \
--cc=openembedded-core@lists.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