Fwd: Bug#729337: xorg-server: FTBFS: preprocessor macro R_SP conflict with glibc headers

Geert Uytterhoeven geert at linux-m68k.org
Tue Nov 12 01:13:57 PST 2013


FYI

---------- Forwarded message ----------
From: Thorsten Glaser <tg at mirbsd.de>
Date: Mon, Nov 11, 2013 at 11:57 PM
Subject: Bug#729337: xorg-server: FTBFS: preprocessor macro R_SP
conflict with glibc headers
To: Debian Bug Tracking System <submit at bugs.debian.org>


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


--
To UNSUBSCRIBE, email to debian-68k-REQUEST at lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org
Archive: http://lists.debian.org/20131111225718.23696.24577.reportbug@ara3.mirbsd.org

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


More information about the xorg-devel mailing list