linux-headers and musl-dev conflict for mman.h and types.h
There is conflict between linux-headers and musl-dev for mman.h and types.h
On Alpine Edge (3.6.3 / Linux version 4.9.32-0-hardened) I have built Openshift Origin from source.
First my build failed with "implicit declaration of function 'mmap'" which I worked around by removing both musl-dev and linux-headers and then adding linux-headers and then musl-dev. Then I continued the build and it hit "unknown type name '__u16'". I then removed the packages again and added first musl-dev and then linux-headers and continued the build. The in which these includes are added makes a huge difference.
When I install linux-headers when musl-dev is not installed, it failed to create 62 files
apk add linux-headers
(1/1) Installing linux-headers (4.4.6-r2)
ERROR: Failed to create usr/include/asm/byteorder.h: No such file or directory
ERROR: Failed to create usr/include/asm/posix_types.h: No such file or directory
ERROR: Failed to create usr/include/asm/mman.h: No such file or directory
I have the feeling that this is a friction between the Linux Kernel ABI and MUSL. It's not life threatening or anything and I don't think it's simple to fix, but it would be nice to hear your opinion and register this as a known issue.
#1 Updated by Timo Teräs about 1 year ago
- Status changed from New to Rejected
I don't understand why the order would affect anything. The packages contain:
~ $ apk info -a linux-headers|grep mman usr/include/asm/mman.h usr/include/linux/mman.h usr/include/asm-generic/mman-common.h usr/include/asm-generic/mman.h ~ $ apk info -a musl-dev|grep mman usr/include/bits/mman.h usr/include/sys/mman.h
It's clearly disjoint set of files, and it would be up to application #include statement to or -I path clause to determine which of the files get included.
I suspect your include is corrupted by local administrative action (or by running some scripts). Perhaps /usr/include's asm, asm-generic, bits, linux, sys directories got redone as symlink to somewhere else. That's the only way the error you reported could happen. I'm marking this as invalid for now, but if you can provide steps to reproduce the error in a clean Alpine system, we can reopen this.