Compiling newlib natively [PATCH]

[Jeff Johnston]

Shaun Jackman wrote:
>>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:
> 
> [clip]
> 
>>to define a number of types.  When newlib's sys/types.h gets included, there is
>>a conflict among a number of the types.
> 
> 
> It seems my linux/time.h has a Debian specific patch. If __KERNEL__ is
> not defined it includes <time.h> (i.e. /usr/include/time.h) instead.
> If __KERNEL__ is defined, my linux/time.h does bring in linux/types.h
> as your does.
> 
> newlib's sys/types.h brings in linux/types.h explicitly. How about
> including newlib's sys/types.h (which seems to work) before including
> linux/time.h, so that linux/types.h is already included in a "safe"
> manner.
> 

This worked for me on my base system.  I will try it out on an FC3 system 
tomorrow and check it in if all goes well and it works for you.  I have attached 
the new patch for /libc/sys/linux/sys/stat.h

> 
>>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.
> 
> 
> My linux/stat.h defines struct kstat, which has a struct timespec
> member, so it includes <linux/time.h> immediately before defining
> struct timespec.
> 
> 
>>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.
> 
> 
> It looks like defining/undefining __KERNEL_STRICT_NAMES would work for
> me as well, though I haven't tested it. I've attached linux/time.h and
> linux/stat.h, as well as linux/types.h.
> 
> I've noticed that my Linux kernel headers are provided by Debian and
> are different than the kernel I'm running (2.6.8.1).
> linux-kernel-headers 2.5.999-test7-bk-16
> 

The experiment of using __KERNEL_STRICT_NAMES failed.  Anyway, hopefully the 
solution above works for you as well.

-- Jeff J.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stat.h.patch
URL: <http://sourceware.org/pipermail/newlib/attachments/20041202/ce8d35e7/attachment.ksh>