Your message dated Mon, 30 Sep 2019 19:26:15 +0200 with message-id <[email protected]> and subject line Fixed since xorg-server 2:1.18.3-2 has caused the Debian Bug report #729337, regarding xorg-server: FTBFS: preprocessor macro R_SP conflict with glibc headers to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 729337: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729337 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Source: xorg-server Version: 2:1.14.99.3-1 Severity: important Justification: fails to build from source (but built successfully in the past) Hi, trying to build xorg-server from experimental because it includes a patch to support the Atari planes for the fbdev module, upstream. Note that the version in sid FTBFS due to this: .../../../../hw/xfree86/int10/xf86x86emu.c:89:5: warning: function might be possible candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] I have no idea why, but (also in #728333 for console-tools) on some buildds, -Werror=format-security is enabled, leading to those. I do suspect this also applies to the version in experimental, given the warnings shown (full build log attached), but the flag does not show up in cowbuilder and on some other buildds, so this is an unknown issue. Anyway, back to the problem at hand: there’s a build failure, basically because xf86x86emu.c #defines R_SP before including <signal.h> which in turn pulls /usr/include/m68k-linux-gnu/sys/ucontext.h in, which *also* defines R_SP (which is apparently valid to do). The R_SP definition in X11 comes from: hw/xfree86/x86emu/x86emu/regs.h <signal.h> comes from: ../../../../include/globals.h There are some ways to fix this, such as including <signal.h> first in regs.h, then #undef-ing all R_* things before redefining them, which (given the existing use of headers-including-headers here) would fit the overall theme, or blaming eglibc (which doesn’t look like a viable solution), or other hacks. I’m tending towards the first way, which is why I file this against xorg-server; please let me know if something like this is acceptable: --- ../../../../hw/xfree86/x86emu/x86emu/regs.h~ 2013-11-11 22:52:33.000000000 +0000 +++ ../../../../hw/xfree86/x86emu/x86emu/regs.h 2013-11-11 22:55:55.000000000 +0000 @@ -39,6 +39,9 @@ #ifndef __X86EMU_REGS_H #define __X86EMU_REGS_H +/* we sometimes clash with system headers, so pull them in here */ +#include <signal.h> + /*---------------------- Macros and type definitions ----------------------*/ #ifdef PACK @@ -117,6 +120,14 @@ }; /* 8 bit registers */ +#undef R_AH +#undef R_AL +#undef R_BH +#undef R_BL +#undef R_CH +#undef R_CL +#undef R_DH +#undef R_DL #define R_AH gen.A.I8_reg.h_reg #define R_AL gen.A.I8_reg.l_reg #define R_BH gen.B.I8_reg.h_reg @@ -127,18 +138,32 @@ #define R_DL gen.D.I8_reg.l_reg /* 16 bit registers */ +#undef R_AX +#undef R_BX +#undef R_CX +#undef R_DX #define R_AX gen.A.I16_reg.x_reg #define R_BX gen.B.I16_reg.x_reg #define R_CX gen.C.I16_reg.x_reg #define R_DX gen.D.I16_reg.x_reg /* 32 bit extended registers */ +#undef R_EAX +#undef R_EBX +#undef R_ECX +#undef R_EDX #define R_EAX gen.A.I32_reg.e_reg #define R_EBX gen.B.I32_reg.e_reg #define R_ECX gen.C.I32_reg.e_reg #define R_EDX gen.D.I32_reg.e_reg /* special registers */ +#undef R_SP +#undef R_BP +#undef R_SI +#undef R_DI +#undef R_IP +#undef R_FLG #define R_SP spc.SP.I16_reg.x_reg #define R_BP spc.BP.I16_reg.x_reg #define R_SI spc.SI.I16_reg.x_reg @@ -147,14 +172,12 @@ #define R_FLG spc.FLAGS /* special registers */ -#define R_SP spc.SP.I16_reg.x_reg -#define R_BP spc.BP.I16_reg.x_reg -#define R_SI spc.SI.I16_reg.x_reg -#define R_DI spc.DI.I16_reg.x_reg -#define R_IP spc.IP.I16_reg.x_reg -#define R_FLG spc.FLAGS - -/* special registers */ +#undef R_ESP +#undef R_EBP +#undef R_ESI +#undef R_EDI +#undef R_EIP +#undef R_EFLG #define R_ESP spc.SP.I32_reg.e_reg #define R_EBP spc.BP.I32_reg.e_reg #define R_ESI spc.SI.I32_reg.e_reg @@ -163,6 +186,12 @@ #define R_EFLG spc.FLAGS /* segment registers */ +#undef R_CS +#undef R_DS +#undef R_SS +#undef R_ES +#undef R_FS +#undef R_GS #define R_CS seg.CS #define R_DS seg.DS #define R_SS seg.SS -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 3.11-1-m68k Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh
--- End Message ---
--- Begin Message ---Package: xorg-server Version: 2:1.18.3-2 This has been fixed by commit 23dfa017298c[1] ("x86emu: Change include order to avoid conflict with system header"), which was apparently first picked up by Debian in version 2:1.18.3-2. At least all builds of xorg-server on m68k have been successful since then[2]. 1. https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/23dfa017298ceceac818f83779858e490c7757b6 2. https://buildd.debian.org/status/logs.php?pkg=xorg-server&arch=m68k
--- End Message ---
