From: Grant Edwards <grant.b.edwards@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] How to use external toolchain that requires --sysroot ?
Date: Fri, 18 Dec 2009 18:55:13 +0000 (UTC) [thread overview]
Message-ID: <hggj6h$b5r$1@ger.gmane.org> (raw)
I'm trying to use an external toolchain (it happens to have
been built by buildroot, but I don't think that matters).
If it is to find library files, the external toolchain requires
that it be passed the --sysroot option. For example:
BTEP=$(BR2_TOOLCHAIN_EXTERNAL_PATH)
$(BTEP)/bin/arm-liux-gcc --sysroot=$(BTEP)/.. -print-file-name=libc.so
If buildroot would go ahead and copy it into staging and then
pass it an appropriate --sysroot, the toolchain would work
fine. However the external toolchain checks in
toolchain/external-toolchain/ext-tool.mk are failing with the
message:
Checking external toolchain settings
Incorrect selection of the C library
This is happens because there is no way to specify that the
external toolchain needs a --sysroot option if it is to be
executed where it's at.
I'd like to be able to have developers all use the same
pre-compiled toolchain. However, I think it's impractical to
expect the external toolchain to always be located in the same
absolute path on the various developer machines. Requiring
that be so makes it difficult to deal with a variety of
situations:
* You might want to be able to switch back and forth between
different toolchains. Building the toolchains with unique
install paths is painful.
* Developers want to be able to do development in "isolated"
non-system directories without having to put the external
toolchain in a global, hard-wired location -- a location
that might be in use by a different project for a different
version/flavor of the toolchain.
I've looked briefly through ext-tool.mk, and it doesn't look
like it would be too difficult to support optionally passing a
sysroot value (perhaps with a default value of "$(BR2_TOOLCHAIN_EXTERNAL_PATH)/..")
to the external toolchain during the checking and importing
steps.
Would such a patch be looked upon favorably?
Or is there already a way to do what I'm trying to do?
--
Grant Edwards grante Yow! I'm encased in the
at lining of a pure pork
visi.com sausage!!
reply other threads:[~2009-12-18 18:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='hggj6h$b5r$1@ger.gmane.org' \
--to=grant.b.edwards@gmail.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