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:
> Boolbool;
>
> "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 . In my case, I hit it
> for the first time yesterday because from ncurses 5.4
> now includes the header.
> So far I see three possible solutions:
> 1) force ncurses to not include . This definitely
> isn't ideal, primarily because it won't stop the next package
> from including , 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 is #included after the headers
being modified here.
Secondly (and perhaps more to the point), is that 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: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 developer and VP. ATI driver and X server internals.
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
