Bug 588270 – Kernel won't build with hardened-musl

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description qweo 2016-07-07 21:44:01 UTC]

Building hardened, gentoo, vanilla or rt-sources on a new hardened-musl system fails as shown in genkernel.log.

[Comment 1 qweo 2016-07-07 21:47:52 UTC]

Created attachment 439998 [details]
Error messages

[Comment 2 qweo 2016-07-07 21:48:29 UTC]

Created attachment 440000 [details]
emerge --info output

[Comment 3 Felix Janda 2016-07-07 22:12:27 UTC]

You should be able to work around this issue by disabling BUILD_DOCSRC.


The issues from the log (there are probably more):

Documentation/misc-devices/mei/mei-amt-version.c:76:27: fatal error: bits/wordsize.h: No such file or directory
Documentation/networking/timestamping/hwtstamp_config.c:114:18: error: ‘caddr_t’ undeclared (first use in this function)
Documentation/networking/timestamping/timestamping.c:296:18: error: ‘caddr_t’ undeclared (first use in this function)

The second and third one can be solved by replacing caddr_t by (void *).
The first one can probably be solved by deleting the #include <bits/wordsize.h> line.

[Comment 4 Mike Gilbert 2016-07-13 01:58:13 UTC]

Giving this to the musl people. Re-assign it if it is not your bug.

[Comment 5 Anthony Basile 2016-07-13 14:52:00 UTC]

(In reply to Felix Janda from comment #3)
> You should be able to work around this issue by disabling BUILD_DOCSRC.
> 
> 
> The issues from the log (there are probably more):
> 
> Documentation/misc-devices/mei/mei-amt-version.c:76:27: fatal error:
> bits/wordsize.h: No such file or directory
> Documentation/networking/timestamping/hwtstamp_config.c:114:18: error:
> ‘caddr_t’ undeclared (first use in this function)
> Documentation/networking/timestamping/timestamping.c:296:18: error:
> ‘caddr_t’ undeclared (first use in this function)
> 
> The second and third one can be solved by replacing caddr_t by (void *).
> The first one can probably be solved by deleting the #include
> <bits/wordsize.h> line.

DOCSRC is full of type errors like that and I've hit a few in uclibc.  Is there any other issues with the kernel source proper?

[Comment 6 Felix Janda 2016-07-13 19:44:14 UTC]

(In reply to Anthony Basile from comment #5)

Once there was a problem with the arm build, introduced in commit
8512287a8165592466cb9cb347ba94892e9c56a5 (in 4.0-rc6) and fixed in commit
13ee9fdba96577eb1583dcd7b15767ef623fae12 (in 4.2-rc1, CCed to stable).

That's the only thing I am aware.

[Comment 7 Michael 'veremitz' Everitt 2019-10-24 14:15:42 UTC]

Is this still a thing?

I'm sure I've built kernels on musl non-hardened systems without issue?