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
next prev parent 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