While compiling XFree86-4.3.0.1 recently, I got the following
error message:
In file included from text-mode.c:47:
loader.h:78: warning: ISO C doesn't support unnamed
structs/unions loader.h:78: unnamed fields of type
other than struct or union are not allowed text-mode.c: In
function `TextMode':
text-mode.c:208: warning: string length `535' is greater than
the length `509' ISO C89 compilers are required to support
make[5]: *** [text-mode.o] Error 1
make[5]: Leaving directory
`/usr/src/incept/BUILD/xc/programs/Xserver/hw/xfree86/xf86cfg'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/usr/src/incept/BUILD/xc/programs/Xserver/hw/xfree86'
make[3]: *** [hw/xfree86] Error 2
make[3]: Leaving directory
`/usr/src/incept/BUILD/xc/programs/Xserver'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/src/incept/BUILD/xc/programs'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/usr/src/incept/BUILD/xc'
make: *** [install] Error 2
I looked into it, and it's occurring because of the following
line in the ValueUnion type:
Bool bool;
^^^^
"bool" is a loaded name. It's a defined type in all C++
compilers, and it's also defined in plain old non-C++ gcc
whenever something includes <stdbool.h>. In my case, I hit it
for the first time yesterday because <curses.h> from ncurses 5.4
now includes the <stdbool.h> header.
So far I see three possible solutions:
1) force ncurses to not include <stdbool.h>. This definitely
isn't ideal, primarily because it won't stop the next package
from including <stdbool.h>, and then we'll be dealing with this
garbage all over again.
2) undefine the bool type before defining the ValueUnion type
(see attached patch). This is hardly ideal, as several other
source files in XFree86 depend on that type, and this could give
us headaches down the road. Plus, I don't know how portable
this hack is--it might not work on other toolchains besides
linux+gcc+libc6.
3) rename the ValueUnion.bool field to something else, like xbool
or boolval. This would be the perfect solution, except that
ValueUnion.bool is part of a documented API for XFree86 driver
modules, and it wouldn't be particularly nice to break the API.
I would assume there would be ABI breakage as well, since I'm
not sure exactly how unions get handled at link-time across
different platforms.
What I'd probably do is go with (2) for the current 4.3.0 branch,
and implement (3) for 4.4.0 or some later release where a driver
API break is marginally acceptable. Anything besides (3) should
just be treated as a temporary stopgap measure, as otherwise
we'd just be digging ourselves deeper into the same hole.
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
Submitted By: Kelledin (kelledin at users dot sourceforge dot net)
Date: 2004-02-18
Initial Package Version: 4.3.0
Upstream Status: Reported to maintainers
Origin: Kelledin
Description: XFree86 4.3.x uses a loaded name ("bool") for a union type field.
This causes nasty compile problems when other stuff (like
ncurses-5.4) includes the <stdbool.h> header. This patch is a
workaround for this issue.
diff -Naur xc/programs/Xserver/hw/xfree86/common/xf86Opt.h xc-bool/programs/Xserver/hw/xfree86/common/xf86Opt.h
--- xc/programs/Xserver/hw/xfree86/common/xf86Opt.h 2001-05-04 14:05:30.000000000 -0500
+++ xc-bool/programs/Xserver/hw/xfree86/common/xf86Opt.h 2004-02-18 14:27:07.000000000 -0600
@@ -5,6 +5,10 @@
#ifndef _XF86_OPT_H_
#define _XF86_OPT_H_
+#ifdef bool
+# undef bool
+#endif
+
typedef struct {
double freq;
int units;
diff -Naur xc/programs/Xserver/hw/xfree86/xf86cfg/loader.h xc-bool/programs/Xserver/hw/xfree86/xf86cfg/loader.h
--- xc/programs/Xserver/hw/xfree86/xf86cfg/loader.h 2001-07-09 18:45:24.000000000 -0500
+++ xc-bool/programs/Xserver/hw/xfree86/xf86cfg/loader.h 2004-02-18 14:26:51.000000000 -0600
@@ -66,6 +66,10 @@
#ifndef LOADER_PRIVATE
/* common/xf86Opt.h */
+#ifdef bool
+# undef bool
+#endif
+
typedef struct {
double freq;
int units;
