Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Issues with the toolchain wrapper applied to the internal toolchain
Date: Wed, 14 Oct 2015 10:56:39 +0200	[thread overview]
Message-ID: <561E18C7.5090201@mind.be> (raw)
In-Reply-To: <561AC198.9070206@mind.be>

On 11-10-15 22:07, Arnout Vandecappelle wrote:
> On 11-10-15 12:08, Thomas Petazzoni wrote:
[snip]
>> As you can see, it looks for the "real" compiler in the wrong location.
>> I believe it should instead re-use some of the logic of
>> BR_CROSS_PATH_REL.
> 
>  Actually I don't see how this could happen, but I'm too tired now to study it
> in detail.

 The problem is that the absolute path is constructed based on $(HOST_DIR)
relative to the location of the executable. That means that the /usr bit is
included. However, in the external toolchain tarballs, the /usr bit is left out.

 I think it's time that we remove the usr part of HOST_DIR. It's quite useless
IMHO. However, it's a pretty big change...

 Specifically for the internal toolchain wrapper, we could calculate abspath
differently for the internal and the external case. Not really ideal if you ask me.


[snip]
>> Also, another concern I have is what going to happen with the double
>> wrapper? A Buildroot toolchain has a wrapper, and then when it's
>> re-used as an external toolchain, another wrapper is created. Will this
>> work OK, especially in terms of ccache behavior?
> 
>  Good point. Also if we add something like that galileo-specific option to the
> toolchain wrapper, we probably don't want it (or repeat it) when used as an
> external toolchain.
> 
>  One solution for both issues would be to deal with buildroot-built toolchains
> explicitly in the toolchain wrapper, i.e. detect the existence of .real and exec
> that one directly. Would that be an acceptable solution?

 Since this solution will be a lot easier, and we probably want it anyway for
the ccache and arch-options issue, I will go for this solution.

 The question is then: do we detect the existence of .real at runtime in the
wrapper itself, or when building the toolchain wrapper?

 I'll try to find time this evening to work this out.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

  reply	other threads:[~2015-10-14  8:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-11 10:08 [Buildroot] Issues with the toolchain wrapper applied to the internal toolchain Thomas Petazzoni
2015-10-11 20:07 ` Arnout Vandecappelle
2015-10-14  8:56   ` Arnout Vandecappelle [this message]
2015-10-14 10:46     ` Peter Korsgaard
2015-10-14  8:58   ` Thomas Petazzoni
2015-10-14  9:20     ` Arnout Vandecappelle
2015-10-14 21:05 ` [Buildroot] [PATCH 1/2] gcc: use '.br_real' instead of '.real' for the wrapped toolchain Arnout Vandecappelle
2015-10-14 21:05   ` [Buildroot] [PATCH 2/2] toolchain-external: bypass buildroot wrapper Arnout Vandecappelle
2015-10-14 21:31     ` Thomas Petazzoni
2015-10-14 21:55       ` Arnout Vandecappelle
2015-10-17  8:52     ` Peter Korsgaard
2015-10-17  8:50   ` [Buildroot] [PATCH 1/2] gcc: use '.br_real' instead of '.real' for the wrapped toolchain Peter Korsgaard

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=561E18C7.5090201@mind.be \
    --to=arnout@mind.be \
    --cc=buildroot@busybox.net \
    /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