From: Michal Marek <mmarek@suse.cz>
To: Stephen Rothwell <sfr@canb.auug.org.au>, Sam Ravnborg <sam@ravnborg.org>
Cc: kbuild <linux-kbuild@vger.kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
David Herrmann <dh.herrmann@googlemail.com>,
Jiri Kosina <jkosina@suse.cz>
Subject: Re: [PATCH v2 0/6] kbuild: use target compiler for user binaries in samples/
Date: Thu, 17 Jul 2014 17:22:18 +0200 [thread overview]
Message-ID: <53C7EA2A.6050301@suse.cz> (raw)
In-Reply-To: <20140714103357.33d3bdc7@canb.auug.org.au>
On 2014-07-14 02:33, Stephen Rothwell wrote:
> Hi Sam,
>
> On Mon, 14 Jul 2014 10:29:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Sun, 13 Jul 2014 20:36:37 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>>>
>>> NOTE: This will likely break the build if the toolchain used do
>>> not include a libc. Let's see how much noise this creates.
>>
>> Then I will drop them from linux-next. Until someone supplies lots of
>> cross compilers with libc support, the samples can not (must not) be
>> built by default.
>
> Just to be clear: for my current build infrastructure, this means
> powerpc and x86_64 hosted cross compilers.
So we basically can have zero, one or both of
A) target toolchain with libc support
B) host toolchain with recent enough kernel headers
Just can idea - in case we have B, but not A, would it make sense to
build $(uapiprogs-y) with the host compiler, but without the
-Iusr/include flag? The question is whether to add a kconfig knob for
this, or some automatic detection for libc support of the target
toolchain. I'll come up with a patch later.
Michal
next prev parent reply other threads:[~2014-07-17 15:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-13 18:36 [PATCH v2 0/6] kbuild: use target compiler for user binaries in samples/ Sam Ravnborg
2014-07-13 18:42 ` [PATCH 1/6] kbuild: add support for building userspace api programs Sam Ravnborg
2014-07-13 18:42 ` [PATCH 2/6] samples: refactor Makefile Sam Ravnborg
2014-07-13 19:25 ` Randy Dunlap
2014-07-13 19:52 ` Sam Ravnborg
2014-07-13 20:13 ` Randy Dunlap
2014-07-14 0:26 ` Stephen Rothwell
2014-07-13 18:42 ` [PATCH 3/6] samples: use uapiprogs support for seccomp Sam Ravnborg
2014-07-16 9:43 ` Masahiro Yamada
2014-07-16 10:31 ` Sam Ravnborg
2014-07-17 3:40 ` Masahiro Yamada
2014-07-13 18:42 ` [PATCH 4/6] samples: use uapiprogs support for hidraw Sam Ravnborg
2014-07-13 18:42 ` [PATCH 5/6] samples: fix warnings in uhid-example Sam Ravnborg
2014-07-13 18:42 ` [PATCH 6/6] samples: use uapiprogs support for uhid Sam Ravnborg
2014-07-13 19:23 ` [PATCH 1/6] kbuild: add support for building userspace api programs Randy Dunlap
2014-07-13 19:53 ` Sam Ravnborg
2014-07-14 0:29 ` [PATCH v2 0/6] kbuild: use target compiler for user binaries in samples/ Stephen Rothwell
2014-07-14 0:33 ` Stephen Rothwell
2014-07-17 15:22 ` Michal Marek [this message]
2014-08-21 13:46 ` Michal Marek
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=53C7EA2A.6050301@suse.cz \
--to=mmarek@suse.cz \
--cc=dh.herrmann@googlemail.com \
--cc=jkosina@suse.cz \
--cc=linux-kbuild@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=sfr@canb.auug.org.au \
--cc=thierry.reding@gmail.com \
/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).