Re: Compiling newlib natively [PATCH]

[Jeff Johnston <jjohnstn at redhat dot com>]

Hmm, this was bound to happen with newlib using a combination of our headers and 
external headers.

I get a problem because my Red Hat linux/time.h brings in linux/types.h.  This 
causes the following:

#ifndef __KERNEL_STRICT_NAMES

typedef __kernel_fd_set         fd_set;
typedef __kernel_dev_t          dev_t;
...

to define a number of types.  When newlib's sys/types.h gets included, there is 
a conflict among a number of the types.

On all of my Red Hat Linux boxes (both old and new), the 
/usr/include/linux/stat.h does not include linux/time.h so I don't run into that 
particular problem with mktime.  I can only assume your linux/time.h isn't 
dragging in linux/types.h or doesn't have the clause above being invoked.  Can 
you attach a copy of your linux/time.h and linux/stat.h so I can try and come up 
with some compromise (a.k.a kludge) that works for both.  My first instinct is 
to try defining/undefining __KERNEL_STRICT_NAMES around the include but it would 
be good to see what your include files are.

-- Jeff J.

Shaun Jackman wrote:
> Certainly. linux/time.h defines a version of mktime that's quite
> different than the version defined in
> newlib/libc/sys/linux/include/time.h. linux/time.h only defines mktime
> if __KERNEL__ is defined. newlib/libc/sys/linux/sys/stat.h defines
> __KERNEL__, includes linux/stat.h, which in turn includes,
> linux/time.h, which redefines mktime. My fix is to include
> linux/time.h before sys/stat.h defines __KERNEL__. I've attached
> glob.i, which illustrates my problem. How does this fix break your
> build?
>
> Cheers,
> Shaun
>
> gcc -I/home/sjackman/work/debian/newlib/newlib-20041126/_build/i686-pc-linux-gnu/newlib/targ-include
> -I/home/sjackman/work/debian/newlib/newlib-20041126/newlib/libc/include
> -DPACKAGE=\"newlib\" -DVERSION=\"1.12.0\" -I.
> -I../../../../../../../newlib/libc/sys/linux/stdlib -O2 -Wall
> -D_I386MACH_ALLOW_HW_INTERRUPTS -DHAVE_FCNTL -fPIC
> -D_I386MACH_NEED_SOTYPE_FUNCTION -DMISSING_SYSCALL_NAMES -fno-builtin
> -O2 -g -O2 -D_GNU_SOURCE -O2 -g -O2 -c
> ../../../../../../../newlib/libc/sys/linux/stdlib/glob.c  -fPIC -DPIC
> -o .libs/glob.o
> In file included from
> /home/sjackman/work/debian/newlib/newlib-20041126/_build/i686-pc-linux-gnu/newlib/targ-include/pthread.h:21,
>                 from /usr/include/bits/libc-lock.h:24,
>                 from
> /home/sjackman/work/debian/newlib/newlib-20041126/_build/i686-pc-linux-gnu/newlib/targ-include/sys/lock.h:14,
>                 from
> /home/sjackman/work/debian/newlib/newlib-20041126/_build/i686-pc-linux-gnu/newlib/targ-include/sys/dirent.h:13,
>                 from
> /home/sjackman/work/debian/newlib/newlib-20041126/newlib/libc/include/dirent.h:6,
>                 from
> ../../../../../../../newlib/libc/sys/linux/stdlib/glob.c:73:
> /home/sjackman/work/debian/newlib/newlib-20041126/_build/i686-pc-linux-gnu/newlib/targ-include/time.h:67:
> error: conflicting types for `mktime'
> /usr/include/linux/time.h:285: error: previous declaration of `mktime'
>
>
> On Wed, 01 Dec 2004 15:43:10 -0500, Jeff Johnston <jjohnstn@redhat.com> wrote:
>
> > Shaun,
> >
> >   Can you discuss the mktime problem that the 2nd part of your patch is fixing?
> >  The change unfortunately breaks my linux newlib build whereas the glob.c
> > change is fine.
> >
> > -- Jeff J.