From: Khem Raj <raj.khem@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] external-toolchain: Detect linux/version.h via cross compiler
Date: Tue, 3 Nov 2020 12:19:32 -0800 [thread overview]
Message-ID: <CAMKF1sofX6BSLHnrzn=gKcVraCaQHKQWP4LoG3ZjYwZiccFovw@mail.gmail.com> (raw)
In-Reply-To: <20201103210038.2afaada6@windsurf.home>
Hello Thomas
On Tue, Nov 3, 2020 at 12:00 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Khem,
>
> Thanks for the patch.
>
> On Fri, 23 Oct 2020 02:36:41 -0700
> Khem Raj <raj.khem@gmail.com> wrote:
>
> > Using linux/version.h is assumed to be hardcoded inside sysroot but this
> > does not consider the case where toolchains might be built with
> > --with-native-system-header-dir which means the header directories will
> > not be under <sysroot>/usr/include but customized, archlinux, debian
> > built cross toolchains use these install settings ( due to multiarch )
> > they have the headers installed like /usr/aarch64-linux-gnu/include and
> > not /usr/aarch64-linux-gnu/usr/include
>
> I am wondering how this can work with Buildroot. Indeed all the logic
> of our external toolchains consists in copying the external toolchain
> sysroot to $STAGING_DIR, and then pointing the cross-compiler to it
> using --sysroot. But if the toolchain headers are not inside the
> sysroot, I think we would not copy them to STAGING_DIR, and therefore
> the rest of the Buildroot logic would not work.
>
> Could you give more details on how this work with regard to how we're
> copying the sysroot to STAGING_DIR ?
It still copied the target pieces to staging area and the compiler
headers and libs are still
used from original install location. so when sysroot is pointing to
new location it can find
the non-compiler specific headers as expected and then use the
compiler headers from
default location and sysroot setting would not have changed that anyway.
The typical usecase is to use distro provided cross compilers, so if a
SDK is generated to use such a setup you would ask the user to
install the distro cross
toolchain and hook it us into buildroot via external toolchain setup
using defconfig
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
next prev parent reply other threads:[~2020-11-03 20:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 9:36 [Buildroot] [PATCH] external-toolchain: Detect linux/version.h via cross compiler Khem Raj
2020-11-03 20:00 ` Thomas Petazzoni
2020-11-03 20:19 ` Khem Raj [this message]
2020-11-03 20:16 ` Yann E. MORIN
2020-11-03 20:25 ` Khem Raj
2020-11-03 20:43 ` Thomas Petazzoni
2020-11-04 3:24 ` Khem Raj
2022-01-08 23:03 ` Thomas Petazzoni
2022-01-13 17:02 ` Khem Raj
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='CAMKF1sofX6BSLHnrzn=gKcVraCaQHKQWP4LoG3ZjYwZiccFovw@mail.gmail.com' \
--to=raj.khem@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;
as well as URLs for NNTP newsgroup(s).