Hi Amy,
On Mon, Jan 16, 2023 at 11:24:19AM -0800, Amy Parker wrote:
> As of recent, my kernel builds have started failing. The error is consistently:
>
> find: 'standard output': Broken pipe
> find: write error
> make[2]: *** [kernel/Makefile:157: kernel/kheaders_data.tar.xz] Error 127
> make[1]: *** [scripts/Makefile.build:504: kernel] Error 2
>
> This fails on the default Arch configuration (6.1.5-arch2-1, defaults
> for all new features) as well as with allmodconfig.
>
> Everything was building fine before - this may be a regression, or
> just may be a problem with something in my toolchain updating and
> causing it to break. In that case, any assistance with getting my
> toolchains back to being able to compile would be appreciated.
I expect this to be due to a change in make 4.4 that ignores SIGPIPEs [0].
So programs called from make will not receive a SIGPIPE when writing to
a closed pipe but instead an EPIPE write error.
`find` does not seem to handle this.
This behavior in make is new and I can't find a reasoning for it.
It also breaks other softwares builds.
For now you can disable CONFIG_IKHEADERS and the build should work
again.
Thomas
[0] make 4.4 was packaged for ArchLinux on 5th of January, so it would
fit the timeline.
On Mon, Jan 16, 2023 at 11:54 AM Thomas Weißschuh <[email protected]> wrote:
> I expect this to be due to a change in make 4.4 that ignores SIGPIPEs [0].
> So programs called from make will not receive a SIGPIPE when writing to
> a closed pipe but instead an EPIPE write error.
> `find` does not seem to handle this.
Thank you so much for the clarification! I've also seen reports of
other tools not handling it (such as `yes').
>
> This behavior in make is new and I can't find a reasoning for it.
> It also breaks other softwares builds.
Are you aware of active discussion regarding this on Savannah, or
should I go and report the effects there?
> For now you can disable CONFIG_IKHEADERS and the build should work
> again.
Alright, thanks. Did that, and re-ran my kernel build (allmodconfig).
All works now.
> [0] make 4.4 was packaged for ArchLinux on 5th of January, so it would
> fit the timeline.
Yep, running Make 4.4.
Jan 16, 2023 17:10:34 Amy Parker <[email protected]>:
> On Mon, Jan 16, 2023 at 11:54 AM Thomas Weißschuh <[email protected]> wrote:
>> I expect this to be due to a change in make 4.4 that ignores SIGPIPEs [0].
>> So programs called from make will not receive a SIGPIPE when writing to
>> a closed pipe but instead an EPIPE write error.
>> `find` does not seem to handle this.
> Thank you so much for the clarification! I've also seen reports of
> other tools not handling it (such as `yes').
Even bash os affected.
>> This behavior in make is new and I can't find a reasoning for it.
>> It also breaks other softwares builds.
>
> Are you aware of active discussion regarding this on Savannah, or
> should I go and report the effects there?
I got a pointer to the discussion after my first mail:
https://savannah.gnu.org/bugs/index.php?63307
It will be fixed in 4.4.1, testing the linked prerelease version would be good.
>> For now you can disable CONFIG_IKHEADERS and the build should work
>> again.
>
> Alright, thanks. Did that, and re-ran my kernel build (allmodconfig).
> All works now.
Nice.
>> [0] make 4.4 was packaged for ArchLinux on 5th of January, so it would
>> fit the timeline.
>
> Yep, running Make 4.4.
Maybe it makes sense to ask for a backport for the fix for the ArchLinux package.
On Mon, Jan 16, 2023 at 03:10:25PM -0800, Amy Parker wrote:
> On Mon, Jan 16, 2023 at 11:54 AM Thomas Wei?schuh <[email protected]> wrote:
> > I expect this to be due to a change in make 4.4 that ignores SIGPIPEs [0].
> > So programs called from make will not receive a SIGPIPE when writing to
> > a closed pipe but instead an EPIPE write error.
> > `find` does not seem to handle this.
>
> Thank you so much for the clarification! I've also seen reports of
> other tools not handling it (such as `yes').
I think this analysis was wrong. For me I got this error because on a
new ArchLinux installation the command "cpio" is not present, leading to
this cryptic error.
I sent a patch to make the error more obvious:
https://lore.kernel.org/all/[email protected]/
Does it work for you after installing the package "cpio"?
It does not explain why it only stopped working for you recently,
though.
> > This behavior in make is new and I can't find a reasoning for it.
> > It also breaks other softwares builds.
>
> Are you aware of active discussion regarding this on Savannah, or
> should I go and report the effects there?
>
> > For now you can disable CONFIG_IKHEADERS and the build should work
> > again.
>
> Alright, thanks. Did that, and re-ran my kernel build (allmodconfig).
> All works now.
>
> > [0] make 4.4 was packaged for ArchLinux on 5th of January, so it would
> > fit the timeline.
>
> Yep, running Make 4.4.