|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] xen: Deal with stdarg.h and -nostdinc
On 26/05/2011 17:11, "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] xen: Deal with stdarg.h and
> -nostdinc"):
>> For compiling the xen kernel we use -nostdinc which means
>> we don't want to rely on any external headers.
>> That also counts vor stdarg.h.
>
> Right, OK, but:
Not really. We are only doing the same as Linux right now. I do note that
they add an -isystem option to their command line, with a gcc include path
that they presumably dump out of gcc in some standard way. However, our
current approach seems to work, if it fails to work in some situation it is
likely to be pretty obvious (build or link failure), and we can fix it then.
This stuff can be moderately fragile, and we've now had no actual bug
reports about it in a long while.
-- Keir
>> Use the external header when we compile the tools.
>> Adapt libelf-loader.c which is compiled in the kernel
>> and with the tools.
>
> -#include <stdarg.h>
> +#include "../../include/xen/stdarg.h"
>
> Firstly, is this correct for all uses of libelf-loader ? This file is
> compiled both for use inside Xen and for use on the host. In the
> latter case it /should/ use the system's stdarg.h.
>
> Also, this kind of relative path should not be necessary. The
> relevant files should be on the include path.
>
> So I think this should be fixed by arranging that your new stdarg.h is
> on the relevant include path, not by changing the .c file.
>
> Ian.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|