Compiling newlib natively [PATCH]
Jeff Johnston
jjohnstn@redhat.com
Wed Dec 1 23:47:00 GMT 2004
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.
More information about the Newlib
mailing list