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