Thanks for the link I do believe that the correct approach for me is to rename BITS_PER_LONG to __BITS_PER_LONG (I just added a sed command in my Dockerfile) and move on with my particular usage, however I am just wondering whether dropping debian10/ubuntu20 in the official qemu ci/ pipeline until it's fixed is the correct approach instead of keep failing it until the error resolves, in a way we want to always know on which OSs the compilation fails for visibility, no?
Thanks again! On Sat, Jun 6, 2020 at 2:49 PM Alex Bennée <alex.ben...@linaro.org> wrote: > > > Sam Eiderman <sam...@google.com> writes: > > > Hi, > > > > I am using debian 10 container to compile qemu too. > > > > I think that what happens here is that > > > > /usr/include/linux/swab.h > > > > Uses BITS_PER_LONG instead of __BITS_PER_LONG which is actually defined > > before > > in qemu at: > > That is indeed the error - we are just waiting for Debian to update > linux-libc-dev with the fix to the kernel headers: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960271 > > > > > include/qemu/bitops.h:#define BITS_PER_LONG (sizeof (unsigned > > long) * BITS_PER_BYTE) > > > > which injects this definition into the linux swab.h header. > > > > By changing BITS_PER_LONG to __BITS_PER_LONG in the linux headers, I > > managed to > > successfully compile qemu. > > > > A different approach would be to move the linux header includes > > (#include <linux/cdrom.h>) in file-posix.c above all other includes - which > > in > > some way makes more sense (since we probaly don't want qemu defines to > > control > > linux headers) but it requires a more complex refactoring. > > > -- > Alex Bennée
