On Wed, 18 Feb 2004, Kelledin wrote: > 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. First off, 2) doesn't work if <stdbool.h> is #included after the headers being modified here. Secondly (and perhaps more to the point), is that <stdbool.h> is a very recent (glibc-wise) invention (read: bleeding edge). So, in your shoes, I'd first talk to the glibc people about the implications of an stdbool.h in the first place. Marc. +----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: tsi@xxxxxxxxxxx | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 developer and VP. ATI driver and X server internals. _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
