[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.