All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

      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 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.