Re: [Xen-devel] [PATCH 3/3] xen: Add stdbool.h workaround for BSD.

[Tim Deegan <tim@xxxxxxx>]

At 14:48 +0100 on 19 Aug (1376923719), Ian Jackson wrote:
> Tim Deegan writes ("[PATCH 3/3] xen: Add stdbool.h workaround for BSD."):
> > On *BSD, stdbool.h lives in /usr/include, but we don't want to have
> > that on the search path in case we pick up any headers from the build
> > host's C libraries.
> > 
> > Copy the equivalent hack already in place for stdarg.h: on all
> > supported compilers the contents of stdbool.h are trivial, so just
> > supply the things we need in a xen/stdbool.h header.
> 
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> 
> The only alternative is to try to reconstruct the compiler-specific
> include directory using gcc --print-libgcc-file-name and seddery.

Sadly, not even that.  In these BSD systems, the compiler's headers and
libraries are bundled in with the rest of the system libraries,  e.g.:

ocelot:tjd$ gcc --print-libgcc-file-name
/usr/lib/libgcc.a

so it would be a matter of finding the headers we want in /usr/include
and pulling on that string to grab all the headers they #include, and
copying them somewhere on the Xen build's include path.  Something like:

ocelot:tjd$ gcc -E -include stdarg.h -x c /dev/null | grep '^# 1 "/usr'
# 1 "/usr/include/stdarg.h" 1 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 1 "/usr/include/sys/_types.h" 1 3 4
# 1 "/usr/include/machine/_types.h" 1 3 4

Bleah. :(

I don't feel too bad about just defining up the bits of stdarg and
stdbool that we need; after all we do that for a bunch of other
compiler-specific things.

Another approach would be to put those definitions into compiler.h and
stop including the compiler's headers altogether, even on linux -- after
all we don't link against libgcc.a either.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel