~kennylevinsen/seatd-devel

1

Alpine Linux build issue

Details
Message ID
<OhUAZ2hmkrjgAaJ1lw2c5tJe3DteCP7y5ii9jfaJ9Bl04RqldpfG7JjuUz11cvpvz77e-0Bau0uhY6B5_TPAdSzVy7nDnIA_CygCPuJeupU=@protonmail.com>
DKIM signature
pass
Download raw message
Hello,

I would like to ask about a build issue I encountered on Alpine Linux specifically on the
ppc64le musl-libc target where building seatd fails due to all warnings being treated
as errors.

The warning I receive is:
../common/evdev.c:27:26: error: overflow in conversion from 'long unsigned int' to 'int' changes value from '2147763601' to '-2147203695' [-Werror=overflow]
   27 |         return ioctl(fd, EVIOCREVOKE, NULL);
      |                          ^~~~~~~~~~~
cc1: all warnings being treated as errors

The full build-log is below and I also included a raw attachment:
https://gitlab.alpinelinux.org/alpine/aports/-/jobs/584289#L208

musl defines the ioctl function prototype as:
int ioctl (int, int, ...);

https://git.musl-libc.org/cgit/musl/tree/include/sys/ioctl.h#n115

whereas glibc defines it as:
extern int __ioctl (int __fd, unsigned long int __request, ...);

https://sourceware.org/git/?p=glibc.git;a=blob;f=include/sys/ioctl.h;h=dd7c3c7c9cabaa12403c4b987f88eb327f1b9d06;hb=HEAD#l7

I created a patch which does an explicit type cast but I am not entirely sure if it is
the correct solution or if it results in bits getting lost (unsigned long int -> int).

My patch is here:
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29188/diffs#diff-content-6b9ab223e670421d2b3e35e9e384d8e768d21ff8

Would it be a good idea to forward the patch upstream or should we configure the build
with -Dwerror=false?

Thanks in advance.
Details
Message ID
<BWU85R.9HNMWS0ZEZL41@kl.wtf>
In-Reply-To
<OhUAZ2hmkrjgAaJ1lw2c5tJe3DteCP7y5ii9jfaJ9Bl04RqldpfG7JjuUz11cvpvz77e-0Bau0uhY6B5_TPAdSzVy7nDnIA_CygCPuJeupU=@protonmail.com> (view parent)
DKIM signature
pass
Download raw message
See: https://todo.sr.ht/~kennylevinsen/seatd/10

I'm not sure what I think about ifdef'ing glibc/musl and casting the 
kernel-provided constants around. I suspect we'd be better off just 
disabling Werror on these platforms.
Reply to thread Export thread (mbox)