Hi, First of all, I just realized that the linux kernel now provides a libc6-dev-arc-cross package in addition to linux-libc-dev. I got tricked by the fact that cross-toolchain-base-ports is able to use the multiarch headers, and it uses them since it stopped building the libc6-dev-$arch-cross packages. Except for the arc architectures as linux-libc-dev doesn't provide the headers for that architecture, hence the FTBFS.
Therefore let me answer you the rest of the mail with that in mind. On 2026-08-13 21:08, Bastian Blank wrote: > Hi > > On Thu, Aug 13, 2026 at 08:40:15PM +0200, Aurelien Jarno wrote: > > It does matter. Your solution works at build time, but it doesn't work > > at runtime. > > What are you talking about?!? runtime or build time does not make a > difference on the existence of the kernel headers in > /usr/GNU_HOST/include. Please explain how this could happen. I meant as runtime, like when using arc-linux-gnu-gcc with the libc-dev-arc-cross package installed. But you are correct that the cross compiler is also able to use the headers provided by the linux-libc-dev-arc-cross build from src:linux. > > Something has to provide the kernel headers for the cross > > glibc and cross compiler to work. In the past it was > > linux-libc-dev-arc-cross and libc6-dev-arc-cross depends on it for that > > purpose. > > And what changed? libc6-dev-arc-cross still depends on > linux-libc-dev-arc-cross, at least if this was not broken due to related > changes in cross-toolchain-base-ports. Sorry you are correct, I thought linux-libc-dev was supposed to provide that instead of linux-libc-dev-arc-cross. > > Therefore I see two options: > > - linux-libc-dev provides the arc kernel headers > > It does?!? Yes, correct, sorry about the confusion. > > - cross-toolchaine-base-ports continues to build > > linux-libc-dev-arc-cross > > No, src:linux provides linux-libc-dev-arc-cross. If you think this is > incorrect, please talk to the CTTE, as this is part of a understanding > created within their reach last year at DebConf 25. With a full view of the problem I agree the current solution is fine. Therefore I believe the patch you proposed earlier is indeed correct. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
