Re: [Minios-devel] [PATCH 18/40] mini-os: fix the compilor error in time

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 06/11/17 14:29, Samuel Thibault wrote:
> Hello,
>
> Julien Grall, on lun. 06 nov. 2017 14:22:45 +0000, wrote:
> > On 03/11/17 17:36, Samuel Thibault wrote:
> > > Huang Shijie, on ven. 03 nov. 2017 03:11:55 +0000, wrote:
> > > > In file included from /usr/include/aarch64-linux-gnu/sys/select.h:45:0,
> > > >                    from /usr/include/aarch64-linux-gnu/sys/types.h:219,
> > > >                    from /usr/include/stdlib.h:314,
> > > We don't want to pull these, that's where we should fix the issue. I'd
> > > say modify include/stdlib.h into #ifdef HAVE_LIBC #include_next
> > > <stdlib.h> #endif, and see what libfdt_env.h actually needs from
> > > stdlib.h, and see how we can provide it.
> > >
> > > > +#ifndef _STRUCT_TIMEVAL
> > > > +#define _STRUCT_TIMEVAL        1
> > > These are non-standard macros, that's why we just don't want to pull
> > > host-libc-provided headers.
> > Sadly, this is not the only place where mini-OS might use the
> > host-libc-provided headers.
> >
> > For instance blkfront.c is included stdint.h. That will pull host libc
> > headers if Mini-OS is not using a libc.
> stdint.h is much less concerning than stdlib.h :)
I would disagree here. I think cross-compilation will be the main way to 
build Mini-OS arm64/arm32.
I don't think you can assume that libc headers will provide enough valid 
information to build arm64/arm32.
> Anyway, we don't want to add more of such leaks :)
Agree here.

> > This makes me wonder, why does Mini-OS is not using -nostdinc to prevent
> > suck leak?
> Perhaps that was posing other problems, but that's an option to
> consider, yes.
>
> Samuel
--
Julien Grall

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel