linux-libc-dev package is broken on rpi2/armhf (it contains arm64 files)

[peci1]

I just wanted to build an app that uses #include <signal.h>, and the build failed with:

In file included from /usr/include/arm-linux-gnueabihf/bits/sigcontext.h:30,
                 from /usr/include/signal.h:291,
                 from util.c:22:
/usr/include/arm-linux-gnueabihf/asm/sigcontext.h:77:2: error: unknown type name ‘__uint128_t’
   77 |  __uint128_t vregs[32];
      |  ^~~~~~~~~~~

That seemed weird to me as I run a 32bit Xbian and I know that uint128 is not supported on armhf at all (not even via emulation). So it seemed to me weird that a system library wants to include something it should know it can not compile.

Then I discovered the file asm/sigcontext.h differes significantly between armhf and arm64. And to my surprise, I found the arm64 copy of the file on my system installed by package linux-libc-dev.

$ apt-cache policy linux-libc-dev
linux-libc-dev:
  Installed: 5.15.80-1669565611
  Candidate: 5.15.80-1669565611
  Version table:
 *** 5.15.80-1669565611 1001
        500 http://apt.xbian.org stable/rpi2-bullseye armhf Packages
        100 /var/lib/dpkg/status
     5.15.80-1669562019 1001
        500 http://apt.xbian.org stable/rpi2-bullseye armhf Packages
     5.15.72-1665077134 1001
        500 http://apt.xbian.org stable/rpi2-bullseye armhf Packages
     5.10.158-2 500
        500 http://deb.debian.org/debian bullseye/main armhf Packages

The deb file http://apt.xbian.org/pool/stable/rpi2-bullseye/l/linux-libc-dev/linux-libc-dev_5.15.80-1669565611_armhf.deb installed on my system indeed contains the arm64 version of the file. And as you can see, I'm using the official XBian-distributed DEB.

Looking around, it seems to me these lines might need an update:

https://github.com/xbianonpi/xbian-package-kernel/blob/90c35293f0b4d0ed71028d06e508d622b18d52fa/hooks.d/post-deb.d/02-kernel-headers#L193-L194

But maybe I'm also completely wrong. I don't understand the XBian build process, so I won't try to guess any more than this.

To reproduce this bug, it's as easy as installing linux-libc-dev, build-essential and running:

echo "#include <signal.h>" | gcc -x c -

[mkreisl]

Please install version 5.15.80-1669562019 instead of 5.15.80-1669565611

...2019 belongs to the 32bit kernel (linux-image-bcm2836), which you must have installed on a Raspberry Pi2, and ...5611 belongs to the 64bit kernel (linux-image-bcm2836).

[peci1]

5611 belongs to the 64bit kernel (linux-image-bcm2836).

Did you mean linux-image-bcm2837 for the 64bit kernel? I have linux-image-bcm2836 installed. linux-image-bcm2837 is not installed. Anyways, I don't see how any of these would affect what version of linux-libc-dev is installed. Neither has a dependency nor breaks this package.

I think what is wrong is that the rpi2-bullseye part of the repo is offerring the 64bit versions, which end up having higher version numbers and thus win the selection process for who gets installed. Or do you explicitly want to support installing a 64bit kernel on 32bit systems? But then these libc-dev packages should actually depend on the type of the installed kernel.

I think this Xbian underwent an in-place upgrade from RPi 2B to RPi 4B, so I might have done something wrong in the process, but it seems to me at least /etc/apt/sources.list look as clean as it could.

[mkreisl]

Please do not discuss, just do what i suggested

By default the 32bit kernel is installed, it runs on Pi2-4 If you want, you can install the 64bit kernel afterwards on 64bit capable processors.

[peci1]

Manually forcing version 5.15.80-1669562019 is something I'm about to do in a while. However, that will break with the next kernel update, if I'm not missing something. Is there a long-term solution to having the correct package installed?

[mkreisl]

I still have to think about if and what to do about it. So far the problem has not occurred, the option to install a 64bit kernel is available since April this year

[peci1]

I've downgraded linux-libc-dev to 5.15.80-1669562019 and I can confirm the installed headers now correctly correspond to 32bit ARM.

I was also surprised this change has been in XBian for quite a long time and nobody reported a similar bug. Maybe not many people actually build C programs on XBian? And from those that do, maybe not so many use the kernel uapi functions?

[mkreisl]

I was also surprised this change has been in XBian for quite a long time and nobody reported a similar bug. Maybe not many people actually build C programs on XBian? And from those that do, maybe not so many use the kernel uapi functions?

You can be sure of that. 99.9999% of users install the image, configure a little Kodi and that's it. And to be honest, that's basically what XBian is for.

Even I have never compiled anything directly on the Raspberry Pi.

But I do have one good news. I think I have fixed the problem, but I have to test it the next days. Let's see when I find time for it

[peci1]

You're right, even for me this was the first time I installed build-essential on this particular Xbian (I think I've been running it for 5+ years).

Thanks for thinking about the fix. Let me know if/when you want me to test it.

[mkreisl]

Since my first two attempts both failed, I have now found a way via pinning. This does not work perfectly, but at least it is now much better than before

What is not handled directly is a kernel architecture change from 32bit to 64bit or vice versa with already installed package linux-libc-dev or if the kernel version (not the last two digits) has changed. In these cases an apt-get install linux-libc-dev has to be done again manually. But this does not happen that often

[peci1]

Thanks! I confirm this is now working correctly on my 32bit Xbian.