From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] Allow Buildroot to update toolchain
Date: Fri, 27 Sep 2013 19:54:02 +0200 [thread overview]
Message-ID: <20130927195402.3320eeb0@skate> (raw)
In-Reply-To: <F9C551623D2CBB4C9488801D14F864C639AD6B4A@ex-mb1.corp.adtran.com>
Dear ANDY KENNEDY,
On Fri, 27 Sep 2013 15:41:36 +0000, ANDY KENNEDY wrote:
> Okay, I see the difference between my patch and what HOST_DIR does.
> When using HOST_DIR, the normal location of output/host is redirected
> to /opt/somedir then the toolchain, all existing libs, all buildroot
> built libs get dumped into that location.
>
> In my patch, I have made this assumption: The user already has
> a toolchain in /opt/somedir/mytoolchain and desires to keep that
> location. After looking at what the code does, I don't really think
> that I can specify the SAME location for HOST_DIR as it would attempt
> to copy files onto itself (which would then, presumably, error out).
> In the case of using the SYSROOT as the staging directory, ONLY the
> libraries get copied back to the toolchain's sysroot (and the really
> nice thing about this is that the user never has to tell me where to
> put the stuff, I asked the toolchain for the sysroot dir).
>
> So, as I stated before, I'll keep dragging this patch around if you
> don't want to include it into Buildroot, but I believe this may be
> something that others would like to use. But, I've been wrong
> MANY times before ;).
I still don't quite understand your use case. If you don't use
BR2_HOST_DIR=/opt/someplace/ and keep telling your users to use their
original toolchain, they have to pass many options to the compiler and
linker to point to the right library locations. They also don't have
access to the right pkg-config that works in cross-compilation mode
that Buildroot has built.
I *really* believe you should have a deeper look at what it means to
specify a custom BR2_HOST_DIR, I think it's really what you should be
using.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2013-09-27 17:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 20:12 [Buildroot] [PATCH] Allow Buildroot to update toolchain ANDY KENNEDY
2013-09-26 20:28 ` Peter Korsgaard
2013-09-26 20:34 ` ANDY KENNEDY
2013-09-27 8:05 ` Thomas Petazzoni
2013-09-27 14:56 ` ANDY KENNEDY
2013-09-27 15:08 ` ANDY KENNEDY
2013-09-27 15:41 ` ANDY KENNEDY
2013-09-27 17:54 ` Thomas Petazzoni [this message]
2013-09-30 15:40 ` ANDY KENNEDY
2013-10-02 21:27 ` Thomas Petazzoni
2013-10-02 22:11 ` ANDY KENNEDY
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=20130927195402.3320eeb0@skate \
--to=thomas.petazzoni@free-electrons.com \
--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