From: Michael Ellerman <mpe@ellerman.id.au>
To: Kees Cook <keescook@chromium.org>
Cc: Michal Hocko <mhocko@kernel.org>, Will Drewry <wad@chromium.org>,
linux-s390 <linux-s390@vger.kernel.org>,
PowerPC <linuxppc-dev@lists.ozlabs.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: samples/seccomp/ broken when cross compiling s390, ppc allyesconfig
Date: Tue, 13 Feb 2018 21:16:55 +1100 [thread overview]
Message-ID: <87d1192nzc.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <CAGXu5j+DnkUv9pZn93wxA6_2s+c3Ap_Q34OR0weY7Y9MJ1aP9Q@mail.gmail.com>
Kees Cook <keescook@chromium.org> writes:
> On Mon, Feb 12, 2018 at 7:25 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Michal Hocko <mhocko@kernel.org> writes:
>>> Hi,
>>> my build test machinery chokes on samples/seccomp when cross compiling
>>> s390 and ppc64 allyesconfig. This has been the case for quite some
>>> time already but I never found time to look at the problem and report
>>> it. It seems this is not new issue and similar thing happend for
>>> MIPS e9107f88c985 ("samples/seccomp/Makefile: do not build tests if
>>> cross-compiling for MIPS").
>>>
>>> The build logs are attached.
>>>
>>> What is the best way around this? Should we simply skip compilation on
>>> cross compile or is actually anybody relying on that? Or should I simply
>>> disable it for s390 and ppc?
>>
>> The whole thing seems very confused. It's not building for the target,
>> it's building for the host, ie. the Makefile sets hostprogs-m and
>> HOSTCFLAGS etc.
>>
>> So it can't possibly work with cross compiling as it's currently
>> written.
>>
>> Either the Makefile needs some serious work to properly support cross
>> compiling or it should just be disabled when cross compiling.
>
> Hrm, yeah, the goal was to entirely disable cross compiling, but I
> guess we didn't hit it with a hard enough hammer. :)
Do you know why it is written that way? Why doesn't it just try to cross
compile like normal code?
cheers
next prev parent reply other threads:[~2018-02-13 10:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 13:37 samples/seccomp/ broken when cross compiling s390, ppc allyesconfig Michal Hocko
2018-02-13 3:25 ` Michael Ellerman
2018-02-13 3:25 ` Michael Ellerman
2018-02-13 5:54 ` Kees Cook
2018-02-13 8:59 ` Michal Hocko
2018-02-13 10:16 ` Michael Ellerman [this message]
2018-02-13 10:32 ` Michal Hocko
2018-02-13 21:27 ` Kees Cook
2018-02-14 9:20 ` Michal Hocko
2018-02-14 9:20 ` Michal Hocko
2018-02-14 17:14 ` Kees Cook
2018-02-14 17:14 ` Kees Cook
2018-02-14 23:23 ` Michael Ellerman
2018-02-22 13:07 ` Michal Hocko
2018-02-22 17:30 ` Kees Cook
2018-02-23 9:12 ` Michal Hocko
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=87d1192nzc.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@kernel.org \
--cc=wad@chromium.org \
/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.