RE: Compatibility with Debian 4.0?

["Howland Craig D (Craig)" <howland at LGSInnovations dot com>]

Look at the preprocessed output.  Grab the compile line from your make
output and add -E to the line if you're using gcc.  This puts the
preprocessed output into the named file, which includes the places
from which it gets the includes.
 
I am not too familiar with the newlib build process, so once you find
where unistd.h is coming from, perhaps someone else will be able to
help with why.
 
Craig

-----Original Message-----
From: Jason E Miller [mailto:jasonm@MIT.EDU] 
Sent: Monday, November 24, 2008 2:41 PM
To: Howland Craig D (Craig)
Cc: newlib@sources.redhat.com
Subject: RE: Compatibility with Debian 4.0?

Craig,
     I agree that it seems to be getting unistd.h from elsewhere
but I'm not sure how to determine which one it's pulling in.  I'm
guessing that it's getting the one in /usr/include/sys/unistd.h.
I checked and none of the unistd.h files in /usr/include define
the missing values.  I'm not trying to build a full toolchain.
I'm just trying to build a native newlib using the installed gcc.
Maybe that's why it's getting the wrong version?
     I guess the other strong possibility is that it's getting
the version in newlib/libc/sys/linux/sys/ instead of the one you
patched in newlib/libc/include/sys/.  The one in sys/linux/sys
seems to include some system header files (bits/environments.h
and bits/confname.h).  Again, /usr/include/bits/confname.h on my
machine does not contain defines for the missing symbols.
     Let me know if there's any other information I can provide
that might help shed light on this.

    -Jason