[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gitlab-ci: Do not use the standard container images from gitlab
From: |
Sam Eiderman |
Subject: |
Re: gitlab-ci: Do not use the standard container images from gitlab |
Date: |
Sat, 6 Jun 2020 15:38:24 +0300 |
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.bennee@linaro.org> wrote:
>
>
> Sam Eiderman <sameid@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