[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#729337: marked as done (xorg-server: FTBFS: preprocessor macro R_SP conflict with glibc headers)

Your message dated Mon, 30 Sep 2019 19:26:15 +0200
with message-id <87wodp7l1k.fsf@turtle.gmx.de>
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 owner@bugs.debian.org
immediately.)


-- 
729337: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729337
Debian Bug Tracking System
Contact owner@bugs.debian.org 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 ---
Reply to: